4 ms·

Code Inflation (2015) [pdf]

• dvh 8y ago
  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.
  • martinpw 8y ago
    That was the size in 2012. On my current Debian system it is 31k. So I guess the bloating continues.
  • tonyedgecombe 8y ago
    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 8y ago
  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 8y ago
    > 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.