Code Inflation (2015) [pdf]

computer.org

52 points·_ieq6··5 comments

Fascinating. The /bin/true started as an empty script and /bin/false as "exit 1", then someone added -version command (why!?) and then someone added help for this unnecessary -version command. Now it is 22kB binary and it's not even used because bash implements it's own.

You see these things happen in corporates a lot, somewhere in the hierarchy a decree is sent down that every program should have a --version option and that gets implemented without question. The worst of these organisations accrete so many rules that it becomes almost impossible to get any work done.

That was the size in 2012. On my current Debian system it is 31k. So I guess the bloating continues.

One reason this happens, that I've observed, is risk avoidance. If you're working in a mission-critical code path, every line of code has been battle-tested through {m,b,tr}illions of executions over many years. You better have a damn good reason to change it, and if you do, you better be damn sure it works.

You can preach about {unit,functional,integration,load,performance} tests, but tests can only verify a miniscule sliver of the state space of any non-trivial program.

So in that situation, engineers tend to avoid risky changes and to accrete stuff instead. I haven't been convinced that it's unreasonable, either.

> I haven't been convinced that it's unreasonable, either.

Until the company loses the business with a product more expensive than the competition's, because it requires a bigger flash part to house all this accretion. Literally happened to me while I was working for a market leader -- we got beaten by a very recent newcomer who probably followed the same strategy but simply had not got enough accretion time yet.

Reply on news.ycombinator.com