Programming Laws and Reality: Do We Know What We Think We Know?
drdobbs.com
drdobbs.com
> Wirth's Law
> Software performance gets slower faster than hardware speed gets faster.
> This law was formulated by Niklaus Wirth during the days of mainframes and seemed to work for them. However, for networked microprocessors and parallel computing, the law no longer seems to hold.
Certainly it holds for some things. My first computer (late 1970s) started up in less than a second. A decade later I had to wait perhaps 20 seconds. Today waiting a full minute for a computer to get to a usable state is not at all unusual. On the other hand, we have Google, which, in a fraction of a second, can do things undreamed of only a few years ago.
This leads to what I think is an interesting line of inquiry. What kids of software does this law still apply to? Why does it apply there and not elsewhere? And what can we do about it?
http://cacm.acm.org/magazines/2009/5/24648-spending-moores-d...
Microsoft Research has a version of the article (not exactly identical):
http://research.microsoft.com/pubs/70581/tr-2008-69.pdf
I also discuss this in my (unfinished) book, with lots of data:
http://www.amazon.com/Objective-C-Performance-Tuning-Develop...
The whole book is / will be (well, the manuscript is) full of examples of techniques that are 2x, 10x or even 100x slower than necessary, but now "recommended practice", often for no discernible benefit.
* Increased functionality
* Increased programmer productivity (programmers are often more scarce than available CPU cycles)
* The bottlenecks have changed
The thesis being challenged in grandparent (pjmlp):
> It applies to the bloat in software development nowadays with layers on top of layers that seldom add any real value to the product.
implies that we are just being wasteful for no real benefit, but we are obviously getting more functionality in or writing more software via increased programmer productivity. Now that power is more of an issue for mobile, we are seeing programmers be more thrifty again, but that is not without a cost in productivity.
- Compiling to a VM + JIT instead of AOT compilation
- Running a programming language VM with an OS agnostic runtime, on a OS VM running on a hypervisor, instead of running the said programming language VM on top of the hypervisor directly
- Use of data structures and algorithms that take much more memory and are slower, because many developers lack proper knowledge to use the right ones and use whatever first result comes on their IDE completion suggestions
Just a few examples out of my head.
Sun tried this and the code actually got slower.
> Running a programming language VM with an OS agnostic runtime, on a OS VM running on a hypervisor, instead of running the said programming language VM on top of the hypervisor directly
Flexibility to run on a VM is a huge time saver.
> Use of data structures and algorithms that take much more memory and are slower, because many developers lack proper knowledge to use the right ones and use whatever first result comes on their IDE completion suggestions
Cheaper (less skilled) programmers means more code can get written (for better or worse).
Who is speaking about Java here?
Optimizing compilers for other languages are a proof that AOT compilation at the end wins.
> Flexibility to run on a VM is a huge time saver.
Of course it is, we just don't need the huge amount of layers the current VM cakes have. Software needs to go to the gym.
> Cheaper (less skilled) programmers means more code can get written (for better or worse).
Ergo less quality that leads to software bloat like Wirth states.
Worse is better. At least better than nothing.
Other than that, I stand by my point that modern software has lots of bloat of useless layers.
Two points: 1) at one point in time, I triple booted between Windows, BeOS (yes it's a long time ago) and Linux: Linux and Windows booted far slowly than BeOS (don't remember exactly but it was >1min while BeOS was 14sec) and afterwards felt less responsive than BeOS.. BeOS is dead though (yes, I know about Haiku).
2) Buy a SSD and you won't have to wait anymore 'a full minute' to have your computer in an usable state..
The discipline of software development is about as rigorous as parapsychology. To learn what we really know about software, I recommend Making Software: What Really Works & Why We Believe It[1], The Leprechauns of Software Engineering[2], and browsing It Will Never Work in Theory[3].
And no matter what languages, testing frameworks, or methodologies you use, always remember:
Every "bug" or defect in software is the result of a mismatch between a person's assumptions, beliefs or mental model of something (a.k.a. "the map"), and the reality of the corresponding situation (a.k.a. "the territory").[4]
If you want your map to reflect the territory accurately, you'll need more than a few "laws" handed down as gospel.
1. https://www.amazon.com/Making-Software-Really-Works-Believe-...
2. https://leanpub.com/leprechauns
3. http://neverworkintheory.org/
4. http://lesswrong.com/lw/2rb/why_learning_programming_is_a_gr...
I have the image of a self-titled "software engineering consultant" trying to gain prestige (and funding) by using lots of big words (i.e. bullshitting).
In my experience, projects large and small are typically cancelled because executive management changes their minds, not because of poor quality.
Certainly there are lots of famous examples of projects that crumble under their own weight, but I really don't think it's anything like 35%.
Business goals change (for better or for worse), market conditions change, egos change, etc.
One cultural difference seems to be that a CEO of a Fortune 500 company who writes off a billion dollar investment due to a change in business strategy is a visionary who makes brave decisions, but anyone who writes off a project/division due to a billion dollars in technical debt is going to be tarred and feathered for blundering.