The most well-known quote about optimization in software development must surely be Knuth's:

"Premature optimization is the root of all evil"

However, what exactly does he mean by optimization in this case? I suspect that he using the word in a very software-specific way, to mean "deviating from generally accepted good practices in order to achieve a specific aim". A case in point would be denormalising a relational database (i.e. departing from the generally accepted good practice of using the 3rd normal form (TNF) of entity relationships), usually in order to the boost performance of commonly used queries beyond that which could be achieved with indexes alone.

Recently, though, I have been struck by the idea (probably not new) that the generally accepted good practices referred to above can themselves be thought of as an optimization (in its more conventional sense). My reasoning goes as follows:

  • The software development process has certain costs (time and money being the obvious ones), and aims to produce a product with certain desirable attributes (reliability, speed, scalability and maintainability to name just a few). There are also certain properties of the process itself which are seen as advantageous, such as visibility and the reduction of risk.
  • The activities which form part of the process (analysis, design, coding, documentation/commenting, testing, etc.) have a cost-benefit profile, which is usually dependent on the lifecycle model and tools being used, and on the size and experience of the team doing the development.
  • Each development project will have a different set of weightings for the costs and benefits, but something can be considered generally good practice if it produces a weighted cost-benefit ratio that is near optimal over a range of scenarios.

An extreme example of this is the fact that most developers would, justifiably, produce uncommented code in a scripting language if all they required was a tool for one-off use.

More subtlely, though, I believe that this in part explains why agile techniques (or extreme programming to give it its less-manager friendly alternative name) have started to replace more traditional, "Code Complete"-esque ones; the reason being that they produce better cost-benefit ratios with today's methodologies, languages and tools (more OO emphasis, better tools and hardware), whereas the more traditional approaches were optimized for what was common a few years ago when modular coding was the norm, development tools were less sophisticated and both development and customer PCs were less powerful.