Make it run, make it right, make it fast, make it small

Problem When should you optimize?

Context You're attacking a new business problem. The solution must be faster-better-cheaper, as usual, and you need a development strategy to balance market, customer, and organizational requirements.

Forces Optimizations have both short and long-term costs. Early optimization runs the risk of high cost with little payback.

Developers usually can't predict where the "hot spots" of their design will be. Postponing optimization until the hot spots can actually be demonstrated is often wise.

"More computing sins are committed in the name of efficiency than for any other single reason - including blind stupidity" [William Wulf]. Improved efficiency comes at the cost of practically every other desirable product attribute [Martin Carroll and Margaret Ellis].

Incremental development has a very positive effect on developer morale. Having "something" that "runs" early in the development effort, and then is incrementally "fleshed out", keeps enthusiasm and vision at a high level.

Fast products produce better customer throughput and delight. Small products are more deliverable and maintainable. Products that produce correct results are entirely desirable.

Solution Build an iterative development strategy around these four activities in this order:
  1. make it run
  2. make it right
  3. make it fast
  4. make it small
Resulting
context
Efficiency doesn't unduly compromise good architecture and product design. Project team focus and morale levels stay elevated. Only those optimizations that are demonstrated to be necessary are actually pursued.

[Source: James Coplien and Kent Beck, "After all, we can't ignore efficiency - part 2", C++ Report, Jul 96, p72]