Premature Optimization and The Web
I had an interesting conversation with Nir Yariv a couple of weeks ago in which we got to talk the meaning of the well-known (and probably my favorite) software development moto: “Premature optimization is the root of all evil”, coined by C. A. R. Hoare, and the special meaning it has in modern web development environments.
In my opinion, “Premature Optimization” is the very common practice of spending too much time optimizing something before we even know it needs optimization. Many developers, including myself, tend to seriously try to optimize things even when it’s not cost-effective or productive, just because we want to do things elegantly. But when exactly is optimization not premature? And what does it mean specifically in web development? That’s an interesting question, and a sort of question us techies tend to neglect too often.
I meet with lots of professional web development teams, in companies ranging from the smallest shops and startups to the largest web enterprises world wide. Almost all of them have something in common: They have no time. They all work in a market-driven (and too often marketing-driven) environments: priorities change daily and new feature requests keep coming in with very little quiet periods. There is no time (and sometimes no will from the management) to fix bugs, and especially no time to optimize. Beyond that, most of the applications they develop go through a different life-cycle than traditional software release cycles: the application is built, released once, and then (perhaps due to lack of time / resources / bad release management) it is patched and patched and patched. The application never goes through a second “release” - so when should the optimization phase be performed?
I’ve been thinking about this allot, and I came up with an interesting conclusion: “Premature Optimization” in web applications mean focusing on performance instead of on maintainability, modularity, flexibility and generally knowing your code well. I’m not saying performance is not important: you should develop with performance in mind. But it should not come at the expense of maintainability and modularity - because those will allow you to both fix bugs and scale easily when the time comes.
These thoughts are not revolutionary, but I think they make an important note, especially today when code generation is so popular, PHP source code to C extension conversion pops up again, and claims that source code documentation is overrated are heard (here and here).
Having this conclusions in mind, I came up with a short (partial) list of tips for people who start writing a web application and want to know where to put their focus:
- Write maintainable code - in other words, decide on coding standards and follow them. In many cases it also means go OOP - but not always.
- Write modular code - Yes, OOP again, but I think that in modern web applications it comes down to one important concept: MVC. You don’t have to use a bloated MVC framework - but separate your tiers. It’s worth it.
- Document - Being able to scale means being able to bring in new developers that will be able to jump into the water as soon as possible. The more in-line documentation you’ll have, the easier it will be for them to both understand how the application works and learn from other people’s experience.
- Keep it Simple - If you’re going with a framework, make sure you know it well enough to hack it when it comes to it. Make sure you create (or use) a modular framework, that allows you to decouple tasks. Do things the UNIX way - small and simple tools that perform a single task and perform it well.
- Be Careful with Code Generation - Again, just like with frameworks, ode generation is a double-edged sword. Too much of it - and you won’t know what your application does. If you use some auto-generator, make sure you study it’s output well.
I’m sure this list can be extended, but my main point is - don’t over do things. Do things in a way you’ll be able to easily improve them when you need to, and release on time. You’ll thank yourself when you’re slashdotted.
So true. We are currently developing an application that is a sale platform. We are developing a release #2 exactly because of the performance and poor scalability. Now everything is in .NET 2.0, with OOP, WCF, ASP.NET AJAX, MVC, etc…
All good practices are being used and it’s scalable, maintainable and god damn fast. It’s more important about making sure that everything is called properly at the right time rather than trying to gain 0.00003 seconds on a operation. Especially if the company lose X hours/days/weeks in billable hours.
Great article.
[...] (Via Premature Optimization.) [...]
[...] read more | digg story [...]
[...] Is not premature optimization evil (advocated first by Tony Hoare and restated by Donald Knuth)? So what gives? [...]