Balancing Performance and Convention

markmcb writes "My development team was recently brainstorming over finding a practical solution to the problem that's haunted anyone who's ever used a framework: convention vs. customization. We specifically use Rails, and like most frameworks, it's great for 95% of our situations, but it's creating big bottlenecks for the other 5%. Our biggest worry isn't necessarily that we don't know how to customize, but rather that we won't have the resources to maintain customized code going forward; it's quite simple to update Rails as it matures versus the alternative. What have your experiences been with this problem? Have you found any best practices to avoid digging custom holes you can't climb out of?"

Comments

Switch to django and python for starters

[1155]

I worked in a small shop that used rails, we found that rails is... constricting, just for the reasons you posted to slashdot for. We looked at our options and switched to django+python. Maintenance wasn't a problem after that. I'd suggest investigating a switch now while you have an opportunity.

Re:Switch to django and python for starters

[latentevent]

Comments like this really don't address the core issues. Frameworks, and especially heavily-developed ones like Django/Rails, are rarely cause for insurmountable performance problems. Of course, caching and setting up distributed workload processing queues will be necessary in any framework, but that's up to the development team working on a specific app rather than the framework itself.

I've been working on a large Rails application for over a year, and we haven't found any scaling issues related to Rails. Instead, there are a number of things that we've done in our application in order to help it scale for our given workload.

That said, there are a number of things that Rails will do to help you scale your application. You may want to look at how Rails 3.0 (the next release of the Rails framework) is incorporating several ideas from Merb to make the framework lighter-weight and more extensible through Rack and the concept of Rails "metals." For offline processing in a Rails app, look at plugins like workling/starling and other message queues. I think you'll find that 1) Rails doesn't have scaling issues, programmers on Rails have several challenges that they have to face to make their applications scalable (just as in any other framework) and 2) As far as providing tools to facilitate developers in scaling their apps, Rails is quite a powerful framework and one that should be given a lot of consideration by development teams.

In conclusion, though, vague comments like "avoid Rails, use Django" are just unproductive spreading of FUD and don't really contribute to any significant discussion or understanding of how to get any of the viable web application development frameworks to scale in any specific case.

Re:Switch to django and python for starters

[Forge]

After reading the linked commentary, I can say there really is a better 4th option. It was even hinted at by the author.

Write your extension/hack as a modification of Rails and/or Ruby. Send them back to the maintainers of said products and see if you can get them inserted as a standard part.

If they do not exact a significant penalty elsewhere for the improved performance in your pretty mundane scenario. It is highly probeble, your changes will be accepted.

This isn't just true for Rails. It's true for any software (except stuff maintained by immature, anal retentive morons.

If it's L/GPL, BSD or other common free license, then this adoption of customer written code is a routine matter. If it's closed source and proprietary they may feel the need to get a lawyer involved and have you sign over all ownership rights to the code you wrote to improve their product (ask for money or stock when that happens).

Either way, in most scenarios good clean extensions tend to get adopted as part of the main program.

PS: Yes. Even "The Evil Empire" (Microsoft, Sun, Apple, IBM etc...) have been known to do this.

Re:Switch to django and python for starters

[arth1]

And when the guy knowing Django moves on, what's the chance of finding a replacements who knows it? How much will that reduce the number of eligible applicants for a position -- will you disqualify fifty really smart guys for five mediocre ones who happen to know Django?

In my experience, being a system administrator for over a generation, what is the most maintainable is to go for standards and well-defined APIs, and document it, document it, document it. Especially document what's obvious and "standard practice", because it may be "standard practice" to do a certain thing in a certain language or certain package, those who come around ten years down the road may not know that this was standard, or why. So document, not so much what you're doing as why. Any coder worth his pizza will figure out what but be clueless as to why.

Re:Switch to django and python for starters

[arth1]

Comments like this really don't address the core issues. Frameworks, and especially heavily-developed ones like Django/Rails, are rarely cause for insurmountable performance problems.

>
No problem is insurmountable. But they are commonly cause for surmountable performance problems. And surmounting costs time and money, while not impressing those who noticed the problems or pay for fixing them.

If in doubt, KISS. Adding extra abstraction layers is generally not simplification. It's like adding another layer of management in a company, in that it is sometimes necessary, but it will rarely increase productivity or responsiveness, at least not in the long term. Especially not when a middle level manager gets replaced with someone who doesn't do things the same way.

Re:Switch to django and python for starters

[Serious Callers Only]

I worked in a small shop that used rails, we found that rails is... constricting, just for the reasons you posted to slashdot for. We looked at our options and switched to django+python. Maintenance wasn't a problem after that. I'd suggest investigating a switch now while you have an opportunity.

Out of interest, what did you find constricting about Rails? Your comment here (and the article, such as it was) are not very illuminating on this score.

I've found it fairly easy to modify, very easy to add plug-ins to, and very easy to add custom SQL queries to if necessary for performance reasons (though most of the time that's not necessary). The only area I can see it being constricting would be when trying to interface with a legacy db structure which can't be changed, in which case Django would have similar problems.

Because the article is not specific enough on the problems they'd like to work around, it asks an unanswerable question - there is no magic formula for trading off convention and performance, no magic bullet; at a certain point you have to stop relying on a framework and add something yourself if it doesn't do what you want or perform to your satisfaction. The same holds true for any framework, and though the received wisdom on Slashdot is that Rails is difficult to work with, or doesn't scale, many companies don't find that to be the case (yellow pages, etc etc).

Re:Switch to django and python for starters

[truthsearch]

The best option is to not use one single framework for all situations unless it's appropriate. Too many developers put blinders on, picking one framework and using it for every project.

My company has a flexible custom framework that we use for the majority of projects. But before we start on any project we discuss the options to see if another framework or open source app would be a better fit. Along with picking the best language for a task, the same should be applied to frameworks.

No need to use Rails or any other particular framework if it doesn't fit the project.

Re:Switch to django and python for starters

[quanticle]

And when the guy knowing Django moves on, what's the chance of finding a replacements who knows it? How much will that reduce the number of eligible applicants for a position -- will you disqualify fifty really smart guys for five mediocre ones who happen to know Django?

Probably not. In my (admittedly limited) experience, I find that Ruby on Rails and Python/Django are similarly supported, and have similar user/developer base sizes. Frankly, if I was choosing between Rails or Django, finding developers for either would be pretty far from the top of the list of my worries.

Re:Switch to django and python for starters

[shirai]

Rails has a lot of problems mixed in with a lot of greatness. For a great many projects, its greatness overcomes its probems.

Its biggest problem, IMHO, is that it does not grow well with the needs of a developer over time. Some things:

* Doesn't scale well
* Not easy to do anything outside the Rails world

I had a conversation with Ezra back when he was starting Merb, and I remember the large resistance to the idea that there were problems with Rails at all. As Merb got released and then popular, it was clear that there are holes in Rails (yes I know they are merging).

At about the same time, I started my own framework (the Caffeine framework now the Go framework) which has not been made open yet (and is not complete yet), but there are several issues that it addresses which could help (a) improve Rails or (b) create other frameworks that can fill holes. I'll mention some of the ideas below.

Note that the original goal was to use Rails for our "very cool application" (tm). Unfortunately we have some pretty lofty goals and Rails turned out to be the wrong tool. I am the CEO of a successful Internet company CityMax (about 30 employees) so I do have experience with the problems that happen after launch and success. They are not the same problems as during the startup phase.

Here are some things that an ideal framework has that I believe are missing or lacking in Rails. Again, I do want to stress that Rails has greatness and that I really respect its creator. That said, I think frameworks can grow to another level.

# Built in scalability and clustering. Should require zero changes (except some configuration) to go from single database to a cluster of databases.
# Reusable code. If you build a feature (like a message board) for one application, that same code should be reusable in another app with zero code changes. It should also be reusable multiple times in the same application. For example, a blog app might use the message board in each blog but there might also be a support message board for the whole system.
# Built in scalable file system. The file should be storable in local, Amazon S3, MogileFS, network share or whatever. Directories can be mapped to any file store (e.g. temp directories might be local, permanent storage might be S3 and archives might be a network share). Should be easy to remap directories and migrate from one data store to the other.
# No magic. Hate it. Makes it hard to figure out and debug the code.
# Custom field types for database, particularly the ability to insert files and images into a database record. The actual files and images are stored in the scalable file system and automatically managed (basically automatic garbage collection for files).
# An image field type where you can change the image sizes (e.g. thumbnail, preview, full size) at will and images are automatically regenerated in those sizes the first time they are needed. This is one of those problems that comes out as you get bigger. Say your shopping cart app stores images in 3 sizes. Now you have 10 million products and you want to add another size. Without this, you are basically stuck with the decision you made at the start.
# Make easy things easy and make hard things easy. In Rails, the solution is usually to memorize the option that allows you to do what you want. With the right design, the problems should be solvable using just Ruby and the framework. This helps keep the framework light and easy to learn over time.
# Discoverable. The framework needs to be easy to figure out on ones own. Merb was more like this. Rails was less.
# Multi-threading. This was one of the primary reasons I didn't want to use Rails originally. I understand that threading is in Rails 2 now but I'm not sure how good it is.
# CouchDB. Okay, this feature is a little cutting edge but the biggest issue after launch is migrating the database. Add a new feature that requires a new column on a table with a bajillion records and you're doing many long midnight runs

Re:Switch to django and python for starters

[CodeBuster]

The parent was not so much saying, "avoid Rails, use Django", but rather was explaining that for about 5% of his necessary requirements, customization of Rails was too complex or expensive when compared to the alternatives. I am myself a web developer and our whole business is really about trade-offs and costs. I have not used Rails personally, but from what I understand, in Ruby on Rails those who go "off the reservation" are "punished" with "ugly code" and complex maintenance for not adhering to the core Rails axiom of convention over customization. If you use Rails and like it then by all means continue using it. There are many web development projects out there that can surely benefit from the convention over customization route (aka why reinvent the wheel). However, there is also something to be said for the ability to "plug" or "hook" into a framework and provide customization where necessary and there are few things as frusterating as getting knee deep into a framework and then stepping on a land mine hidden in the muck because the framework developers were careless or walled off an internal handling area and didn't provide a key handling point, or foothold if you will, where it would be *really* nice to insert a custom strategy for some domain specific reason.

Concentrate on the 5%

[Samschnooks]

You see, the other 95% (Convention as you put it.) you're talking about can be done by anyone: that's one of the reasons frameworks exist. In other words, it can be shipped to the lowest cost country in the World.

The customization is what is going to keep you employed. That's the specialization that keeps the customers from going overseas - even if you're Indian yourself. There's always someone willing to do it for less. No exceptions. So, develop those resources if you want to keep doing what you're doing.

Expand the toolkit

[thethibs]

Would it be out of the question to assess the needs of the troublesome 5% (and perhaps the other 10% that were shoehorned into Rails) and add a framework that's more in line with those needs?

Data exchange is sufficiently mature that interaction between applications in different environments is not an issue, so all you are left with is the added overhead of supporting two frameworks; not a bad thing if you consider the added flexibility of using the framework best suited to each application. Having options is usually a good thing.

Re:Expand the toolkit

[Bearhouse]

Mod up! If the only tool you have is a hammer, you end up treating everything like a nail.

As the OP pointed point, all development environments sooner or later hit this wall. I've never found one, (and am pretty sure that one will never exist), that ticks all the boxes for a typical mixed environment (the GUIs, OLTP, distributed database management, web access, making the coffee...).

In the 80s, I worked for a company that - as was fashionable at the time - developed its own '4GL' and decreed that everyone use it. In a satellite office, we tried, but found that in certain circumstances it just plain would not do what we needed. Guess what? We went back to 'hard coding' those key functions...

Don't worry about it, (after all, same bits of windows, to name just one OS, are written in assembler to speed performance).

So as the man says, expand your toolbox and your competencies - it'll make you a better project manager (to handle the interfaces) and programmer.

Re:Expand the toolkit

[truthsearch]

so all you are left with is the added overhead of supporting two frameworks

And that's often much better than supporting one framework plus your own customizations. Once you customize it's often extremely difficult to upgrade the framework and have your patches still work. So there can be a lot of extra development time involved. Plus just the learning curve to get intimately familiar with the internals of the framework when that's often not necessary.

Hard to say, but...

[SlashDotDotDot]

Making this sort of decision really requires more technical details than you provided in the summary or the linked article.

If you do choose to make custom modifications to Rails (or any other third party dependency in your system), make them very carefully. Keep notes about what you changed, and why. Comment the modified source code with a consistent, searchable tag, like

// MYCOMPANY Begin custom changes
// Optimized this block for queries where the
// search string is only one word long, and
// measured a 20% performance increase on the
// production server under moderate load.
// 3-Jan-2009
...
// MYCOMPANY End custom changes

Also, check the third party source into your own version control system so that you can track the changes explicitly.

Since you are talking about making changes for performance reasons, be sure to follow good optimization practices. Measure first, optimize only the true bottlenecks. Measure under realistic scenarios. If optimizations are even slightly confusing or subtle, comment them thoroughly. Keep the original, unoptimized code, maybe just in comments next to the new code, or maybe in a separate "reference implementation" function so that you can fall back to a known reliable version.

Re:Hard to say, but...

[chachacha]

Keeping commented out code around is not only distracting to developers but harmful. Code in comments isn't syntax checked, isn't compiled, and isn't tested and therefor quickly begins to suffer from bit rot. It would be better to refactor the surrounding code to work with different plugin-able implementations and to fully support both the "old" and the "new and improved" implementation if the intent is to be able to reliably revert that part of the system to a different implementation.

Extend sanely

[Bantik]

First off, I totally agree with Samschnooks that as a development team, that 5% is your responsibility, and what you're really getting paid for. But given your concerns about maintainability, and what I'm reading as your concern that custom code that you create may end up being addressed by the framework, I do have some advice.

See what of your own code can be crafted into a plugin to extend the framework. Rails plugins are quite easy to create and insanely easy to use.

Be diligent about abstracting the functionality that you need, keeping domain-specific business logic out of the plugin and in the application instead. You'll find that plugins are easy to write test cases for and will keep your custom logic very modular.

If someone else ends up releasing a plugin that addresses your needs, you can simply swap it out; the same applies if the framework gets extended to include what you need.

If maintenance is a real issue for you, release the plugin yourself as open source and recruit some assistance from the community. Chances are, you're not the only one in the world who needs the functionality.

welcome to the real world

[speedtux]

Lots of tools have the property that they make the first 95% or so of the solution really easy and the remaining 5% nearly impossible. On balance, you're worse off than if you had done the whole project in another tool.

Build vs. Buy

[michaelmalak]

What you call "convention vs. customization" is really just a special case of "build vs. buy". You can research the standard factors that go into such a decision, but the most important one is whether the part you intend to build is both a) essential to the business and b) something that would give you a competitive advantage over buying.

I agree with the above poster.

[Jane Q. Public]

I work on a major website, all done in Ruby/Rails. We, in contrast, have found that the tremendous ability to customize the framework is liberating, rather than constrictive.

Without knowing much more detail about your problem, it is difficult to give advice. Having created large, complex websites, and maintained them for long periods of time, we have yet to run into intractible problems as a result of the language or framework themselves. The fact that there are many large, complex Ruby on Rails websites being created and maintained by Fortune 500 companies also contradicts the idea that Ruby and Rails have serious, show-stopping shortcomings.

I strongly suspect that part of the problem is that you do not know your platform (in particular, Ruby) as well as you perhaps could. Ruby is very extensible via Gems that are freely available or that you can write yourself, or even just code modules. Rails is similarly, wonderfully extensible via plugins. Plugins are also freely available for just about every situation you can imagine, or again you can write your own.

Ruby is one of the most flexible languages in existence. Rails is hardly perfect, but any shortcomings are easy to code around by adding your own extensions. But expecting any framework to be complete for your purposes, before you begin, is pretty much wishful thinking.

Once again, I do not know enough about your situation. But if you expect any framework to be "plug and play" for very complex tasks, like an erector set, you will be disappointed. There is no substitute for knowledge of your platform, and programming ability.

Just start replacing stuff

[level4]

My company started writing a big app in Rails. We hit limitations (for us) fairly quickly so just started replacing the bits we wanted to work differently. The great thing about Ruby is you can just switch stuff in and out. The great thing about Rails is that it's well-designed enough that you can do that fairly easily.

Sessions, for example. We wanted to share sessions between sites, so just stopped using the Rails one and started using ours. We just put a new session class system in a gem, require it, and talk to that instead of the built-in. Works brilliantly and with a little finesse you can make it totally transparent.

I think the key is to think of Rails as a framework - as in, a literal scaffolding that you place things in. The basic structure is sound enough and very useful. It's filled with some useful default code, but if that doesn't meet your needs, feel free to start replacing it wih things that do.

Write Tests, Open Source, & use Rack

[remitaylor]

[test!]

A good test suite == "best practice to avoid digging custom holes you can't climb out of"

I work at a Rails shop too and, when I/we need to do something highly custom, we create it as a gem (or a Rails plugin) and post it somewhere incase someone else finds it useful. None of the plugins/gems I've released have required any maintenance to speak of, unless I've wanted to add additional features.

Be sure to write tests for your customizations (gem/plugin)! This will make it really easy to discover if your plugin no longer works for the next version of Rails/ActiveRecord/whatever it is you're extending.

[open source!]

If your changes might help other developers (they're not very, very specific to your product), open source them as a gem and let people know how to use it.

Not only can others benefit from your changes, but they can commit back too! Put the gem up on github[1], as it's the current de facto standard home for such things.

[rack it up!]

If you really need crazy performance out of Rails, look into using Rack[2]. Rails 2.3 (currently Rails Edge, will be released this month) *finally* uses Rack. Something like Rails Metal[3] makes it easy to return directly from Rack, letting you *highly* optimize certain requests. This is like rewriting some of your Ruby as C extensions to speed it up - Rack is really easy to use.

Good luck!

[1]: http://github.com/
[2]: http://rack.rubyforge.org/
[3]: http://weblog.rubyonrails.org/2008/12/17/introducing-rails-metal

JRuby

[BrainInAJar]

Why not deploy your app on JRuby, and if there are still performance bottlenecks, write those parts in real Java ?

Contribute

[RAMMS EIN]

``Our biggest worry isn't necessarily that we don't know how to customize, but rather that we won't have the resources to maintain customized code going forward; it's quite simple to update Rails as it matures versus the alternative.''

As Alan Kay said, the best way to predict the future is to invent it. If you are worried about your useful code being broken by a future version of Rails, contribute it to Rails so that that future version will include it. Or, if you can't get it into the framework, make it available as a separate plugin.

Assuming that it's ok to share the code and that the code is useful outside your project, this will allow open source to work for you and ease your maintenance burden. If it's not ok to share the code or it isn't useful outside your project, then it's part of the project and the project will have to carry the cost.

I feel compelled to add

[Jane Q. Public]

that the other serious problems we have had have been programming bugs; but those bugs were due to our own coding or design lapses, not framework limitations.

Most people who speak of "limitations" to their framework are people who expect the framework to do all their work for them: this is simply unrealistic. If that were how it worked, it would not be called a "framework", but rather a "product".

JEE tech is too complex and fragile

[presidenteloco]

We are well into a project that has JBoss SEAM as its basis, but required significant mods to give us multi-database capability and a FLEX front end. So instead of a community maintained opinionated meta-framework, we now have our own super complex, fragile framework cluster(****).

It is also effectively a dense, opaque yarnball. The stack traces of exceptions are so long, due to the interceptor architecture, that the Java stack trace displaying algorithm gives up and prints ...

So my advice would be, at the risk of trolling, but I intend it as a serious debate position, don't start with something as excessively complex as JEE technology.

Because JEE technology is barely manageable, maybe, if you stick EXACTLY to the most popular opinionated meta-framework for it, but if you deviate off the straight and narrow path, you are on your own in a dense jungle with a dull machete.

Ask Slashdot

[starrsoft]

FTFA:

So we have two basic options: pay for bigger hardware, or spend more time writing/maintaining custom code that allows us to live on our existing hardware.

Hardware is Cheap, Programmers are Expensive:

Given the rapid advance of Moore's Law, when does it make sense to throw hardware at a programming problem? As a general rule, I'd say almost always. Consider the average programmer salary here in the US. You probably have several of these programmer guys or gals on staff. I can't speak to how much your servers may cost, or how many of them you may need. Or, maybe you don't need any--perhaps all your code executes on your users' hardware, which is an entirely different scenario. Obviously, situations vary. But even the most rudimentary math will tell you that it'd take a massive hardware outlay to equal the yearly costs of even a modest five person programming team.

Re:Language is not the answer

[quanticle]

I still remain skeptical about the benefits of model-driven-development. I recall that, at the latter end of the 1980s, developers were promised much the same thing with the push toward CASE tools. Of course, developers and managers quickly learned that such tools were only of use in a certain limited number of scenarios, and that attempting to use those tools outside of the scenarios for which they had been designed quickly led to the same problems.

Frankly, I'm not sure that "software entropy" is solvable by any sort of tool or language. Rather, it is solved by training developers to write tests, and enforcing certain minimum style standards on the code, so that any developer can look at any portion of the codebase without feeling too unfamiliar with it.

Version Control

[omb]

I hate code full of company comment cruft.

Use a good VersionControl system, git, murcurial or Subversion if you must, __but__ keep the meta-data out of the code. If you use sensible tools you get all that, and its much easier to work with the upstream,

Re:That's rich!

[Per Bothner]

Java is quite fast, thank you.

Good frameworks provide flexibility

[Anonymous Coward]

The true differences between frameworks are inevitably revealed as soon as you try to build a product of significant complexity. A truly flexible framework makes it easy to override, overload, or otherwise replace functionality WITHOUT having to modify the framework itself. This has long been my issue with a number of web frameworks implemented in a variety of frameworks. There are many frameworks that will make a fairly simple form based web application come together very quickly. If you've got 5-10 forms, a simple data model, and low enough load to run on a single host, there are lots of frameworks that will let you churn out an app in the blink of an eye. But as soon as you have a sophisticated and complex data model, loads that require scaling not just the web layer, but also the persistence layer, across multiple hosts and even multiple data centers, and you have to support a variety of views (html, web services, json for ajax, iphone, pdf, etc), a lot of frameworks fall completely flat and are unable to help and, in many cases, become an active obstruction.

It has been a number of years since I seriously investigate RoR for a web project because the vast majority of my work involves very high performance and high volume sites and when I looked into RoR, it offered no easy mechanism to work cooperatively in a cluster with any more sophistication than sticky load balancing and a single shared db. I'm sure it is much improved since then, but every time I take a quick look-see, it still seems to be very lacking - not just in scalability, but in extensibility in general, and I just can't tolerate that.

There aren't many frameworks that I've encountered that offer the kind of flexibility to really allow you to take our app any direction you want to go. The one that does requires a fair bit more work up front, but boy does it pay off as soon as you have to get sophisticated. Of course, it is native to the language everyone round here loves to hate, Java, but I highly recommend you look into Spring and SpringMVC. Plug in any persistence mechanism you like, including a mixed persistence layer. Plug in any view technology you like. Use AOP to handle cross cutting concerns. You have the flexibility to replace any built-in component with an implementation of your own, so you are never required to modify the source code of the framework itself.

At every turn, SPring has provided the flexibility I've need to build very sophisticated applications for a number of years now. It will take quite a bit to move me to another platform for anything but the simplest of apps. I recommend you check it out. The fact that it runs in a language that is 25x faster than Ruby doesn't hurt any, either. And the ecosystem of useful code is larger for Java than for any other language I'm familiar with. JEE is needlessly complex, but you can do just about everything JEE does via Spring with a tiny fraction of the complexity, and for the very few things spring won't do, Spring will happily expose JEE directly to you. Oh, and I gather it runs in .NET, too, though I have no idea if it is quite as functional, since it is developed from a java-centric paradigm.

Re:That's rich!

[JavaRob]

As I stated before, it may be the fastest in its class, but it still ain't fast.

What do you use when you need something better performing than Ruby? You aren't going to say "hand-tuned assembly language", are you?

I've been using Java for a long time (this may be obvious from my userid & screen name), though it's not the only language I use nowadays.

Startup is slow (though finally they have addressed this for client apps in a recent release, and it's irrelevant for stable server apps); memory consumption is still not optimal (this hasn't seen massive improvements), but performance is excellent nowadays, assuming your code isn't crap (or using some library that's doing a billion extra things at each call).

The stats that show up in various performance shootouts, which place it just a tad behind straight C/C++ and miles ahead of languages like PHP, Perl, Ruby, Python, etc., match up with my experiences pretty well ...though of course actual webapp hotspots are usually in data access or remote communication -- and have nothing to do with the development language.

There are also now more situations where the hotspot compiler can result in *faster* execution than C/C++ because it operates using live runtime performance data, which is obviously unavailable to a static compiler.

Do you have any specifics to point to, or are you just talking?

Big Surprise

[holophrastic]

Those you know me, know me a lot. I had the same problem five years ago. And it started to turn working for clients and revenue-generating work into working for the framework and framework-customizing work.

So I built my own framework, from the ground up.

Now it's all my conventions, and no one else's. I customize in ways that I know will be compatible for future upgrades. Of course, I get to make those upgrades myself too.

But it means that I do everything "for the last time". If it's something that seems valuable, it gets thrown into a framework-compatible routine, and I never need worry about it ever again.

A lot more work early on. A lot more work for quite a while. And then, blissful no work for anything. Seven of the nine things in the "essentials" section of my invoices -- that every client project needs just to start -- amount to 90% of the essentials dollar amount, and amount to, no kidding, the twenty seconds to install hte framework for teh new client -- and by that I mean run the script that copies files, migrates databases, and changes passcodes. From then on, approximately 75% of the work is remembering the name of the existing function -- or looking at another client project to find it; writing documentation simply hasn't made it to the top of the list in five years.

I spend about 85% of my effort dealing with client content/sales/training/trust, and only 15% on the actual programming.