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:
|
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] |