Good, Fast, Cheap: Pick 3 or Get None

submited by

Style Pass

2025-01-06 07:30:06

Engineering is is a game of compromises: we can’t have it all, if we optimise for something, something else got to give. We programmers often like to think of ourselves as engineers (some of us actually are), and one way to project the associated gravitas is to act jaded: there’s no free lunch, pick your battles, and accept that the only way to cheap software is to cut corners.

In the short term, sure: the corners you cut are unlikely to come back to haunt you, and you can sacrifice performance or quality to reduce costs. Long term though, neglecting either can easily start a downward spiral to the infamous Big Ball of Mud.

Yes, even performance: you need your tests to run fast enough, or you’ll be tempted to run them less often, or worse, write fewer of them. Bugs will creep up, and people will become increasingly wary of fixing poor code. Conversely, your program needs to run fast enough for its users, and fixing performance problems late is likely to require significant rework, or ugly hacks.

(For what I even mean by “simple”, see my readability article, read John Ousterhout’s A Philosophy of Software Design, or watch one of his talks).