
Bugs and Battleships (2011) - gklitt
http://blog.ezyang.com/2011/12/bugs-and-battleships/
======
hyperman1
A bit of a tangent, but I notice a bit of a problem with the definition of a
good program: Having a long lifespan is the hallmark of a bad program, not a
good one.

Compare a good program and a bad program: The good one is easy to adapt, and
to decouple. The bad one is an incomprehensible mess with tentacles sprawling
in all kinds of weird directions.

This means over time it is very easy to change and decouple the good one,
causing it to morph to a worse state or shrink. The bad one will resist these
tendencies and stay unmodified in its place. Hence, the only way for a good
program to survive is becoming worse.

This happens especially in enterprise environments: Every few years, someone
enters and decides to change everything. This tends to happen irrespective of
the value of the software.

It always turns out replacing horrible software will cost way to much, cause
huge downtime, and the only person who stil dares touching it has no reason to
change the situation and every reason to defend the fiefdom. Meanwhile, good
software almost nevers survives the new manager syndrome or the hordes of
fresh externals descending on it every few years to rearchitect and refactor
it.

As a bonus, good software is by its nature a good training grounds for
newbies, which rarely ends up making it better.

The end result is an evolutionary process where survival of the fittest ends
up selecting for the worst of the worst software.

