
Code Inflation (2015) [pdf] - nilsocket
https://www.computer.org/cms/Computer.org/ComputingNow/issues/2015/04/mso2015020010.pdf
======
dvh
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.

~~~
tonyedgecombe
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.

------
cle
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.

~~~
minipci1321
> 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.

