Code Inflation (2015) [pdf]
spinroot.com
Code Inflation (2015) [pdf]
1–10 of 39 posts
Re: Code Inflation (2015) [pdf]
#2TLDR
Author rants about how the size of the executable for the Unix `true` command has increased "exponentially" from 0 to 22KB over ~30 years, for no apparent reason other than "because it can", referring to cosmology, of course.
"...true and false commands also don’t need an option that can invert the result, or one that would allow it to send its result by email to a party of your choice."
The article is humorous in nature, but not without a point.
OP, thanks for sharing the article.
Re: Code Inflation (2015) [pdf]
#3Excellent analysis.
I'd like to add that "growth over time" also solves the "No Silver Bullet"[1] paradox: while Brooks's analysis[2] seems obviously correct, we also obviously have code that seems orders of magnitude larger than it has any business being[3].
As far as I can tell, Brooks doesn't consider cumulative effects of growth over time, but only a single iteration of analysis → development. So a 20% difference in efficiency is just a 20% difference in outcome. However, that same 20% inefficiency per iteration yields a 40x difference in outcome over 20 years. Compound interest.
[1] https://en.wikipedia.org/wiki/No_Silver_Bullet
[2] "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.
[3] MS Office is >400MLOC. Xerox PARX had "personal computing" in ~20KLOC. Even assuming MS Office is 100x better at "officing", that leaves 99.5% of the code unaccounted for. Similar analyses can be done for web browser (WWW.app, 5KLOC, Mozilla 15MLOC) and other operating systems etc.
Re: Code Inflation (2015) [pdf]
#4[deleted]
Re: Code Inflation (2015) [pdf]
#5Excellent analysis. I'd like to add that "growth over time" also solves the "No Silver Bullet"[1] paradox: while Brooks's analysis[2] seems obviously correct, we also obviously have code that seems orders of magnitude larger than it has any business being[3]. As far as I can tell, Brooks doesn't consider cumulative effects of growth over time, but only a single iteration of analysis → development. So a 20% difference…
[2] compilers, debuggers, IDE, unit tests, configuration management, PaaS, IaaS...
We could argue, is it half a fold? is it two folds? depends on the day.
Re: Code Inflation (2015) [pdf]
#6Code inflation nicely cancels out gains from Moore's law. But there's also another interesting phenomenon seen in embedded hardware - it seems that each generation of devices has more (exponentially more?) computing power on-board, while the user-facing functionality stays the same or even slightly degrades. For example, the functionality of today's fridges, kettles and washing machines is equivalent to those made 20 years ago, but today's versions will break down faster and in ways nigh impossible to fix by yourself.
We're about to have Android running on toasters. And I can't stop myself from asking the question - why?
Re: Code Inflation (2015) [pdf]
#7Excellent analysis. I'd like to add that "growth over time" also solves the "No Silver Bullet"[1] paradox: while Brooks's analysis[2] seems obviously correct, we also obviously have code that seems orders of magnitude larger than it has any business being[3]. As far as I can tell, Brooks doesn't consider cumulative effects of growth over time, but only a single iteration of analysis → development. So a 20% difference…
Brooks argument if I remember right was about humans software always trying to push the envelope. So it is always going to be hard.
The inflationary phenomena described here is more about incremental decorative and accidental complexity. The root cause is not the human enterprising drive to go boldly where no man gone before.
Looking at the examples of adding headers and command line bells and whistles I wonder what human trait drives this? Those seem (product-)management and architecture/framework type decisions possibly driven by a need to have things uniform and under control.
Moore's law is tiring (it is more obvious on the data center side than in devices yes). Will we become more frugal again?
Re: Code Inflation (2015) [pdf]
#8"the probability of non-trivial defects increases with code size."
Intuitively this feels correct, I wonder if anybody has studied it.
Re: Code Inflation (2015) [pdf]
#9> It sometimes seems as if [software] has just gotten bigger, but not safer. So why is that?
The premise for the article. But it provides no proof of it. And I can just as well say "for me it seems software in general have gotten much safer over the years, because I barely remember a time a program crashed."
Re: Code Inflation (2015) [pdf]
#10"the probability of non-trivial defects increases with code size." Intuitively this feels correct, I wonder if anybody has studied it.
Why does he specifically say "non-trivial" defects? The probability of any defect surely increases with code size?