Monday, March 23
Questions: Is there a useful distinction between bad code, the way programmers experience it, and bad software, the way users experience it? If so, does the former nonetheless lead to the latter? How?
- Bad code makes software hard to maintain. Programs and systems that can't keep up with the world are hard on their users. And hard on the people who have to hack them, who might be thought of as a special kind of user. (Sometimes, as with libraries and APIs, this distinction vanishes.)
- Bad code has spiritual, moral, and intellectual inertia.
- Bad code leads to software that's hard to build on — software which has unreasonable expectations, breaks on too many edge-cases, chokes on its own accidental complexity, and plays poorly with others.
- Bad code models the world not so much incompletely (completeness is usually a fool's game) as pathologically. Incomplete models are often useful; pathological models determine people's lives & work for the worse.
- Bad code doesn't attract as many contributors. (Or as smart a set of them.)
I would like to think that good code (in the sense of clean, coherent, comprehensible, correct, well-crafted) is necessary if not sufficient for good software. I'm not sure I can support that strong of an assertion about the relationship. Lots of useful (and even beloved) software is probably stunning in its tangled ugliness, just below the surface.