I just finished reading the book Geekonomics – the real cost of insecure software. The book sums up commercial software development from a business perspective succinctly:
It is a pretty interesting topic – and should be required for any software professional, especially managers! The author tends to hammer home the same point over and over by comparing the software industry to the auto industry. There is a lot of legal information in the book toward the end. I skimmed the parts that got boring or that I already knew about (like the rise of open source software).
The part about the Therac-25 XRay machine that killed several people due to a software defect is chilling (http://en.wikipedia.org/wiki/Therac-25). I remember being told this story in my first software class in college. It is surprising how few people know of this event. Try/catch block anybody? Defensive programming anybody? The Therac-25 has a downright bazaar UI as you can see in the wiki article. The teacher said the corporate veil was pierced and the developers were charged criminally with manslaughter – I can’t seem to find anything about this though today.
The book talks about hacking and how prolific it is. The idea of a ‘dragon’ hacker who has 100’s of zero day exploits at their disposal is brought up. These are the scary ones that you never see. It is true, the best hackers will never let you know they own your machine. Only the idiots deface a site with their call sign or leave any trace.
Key points from the book:
- We are all crash test dummies in the information age. Identity theft is on the rise, and systems are getting less secure, not more secure.
- Software is still akin to artisan or craftsmen level quality.
- Software defects in medical devices and airplanes have caused deaths. More and more devices are being built to operate by wire – like automobiles.
- It is very hard to regulate software production. The US government wants to stay out of the way to keep the momentum going. In honesty that is probably the lesser of two evils.
- The legal precedent for software makers is to claim no responsibility for defects – THIS SOFTWARE IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED…. In other words, if it breaks, tough luck. It is up to the user to pay for anti-virus, firewalls, and keep the program up to date.
- Software makers need defects in their current build so users will have an incentive to upgrade. Otherwise they put themselves out of business.
- More features = more bugs, but the market seems to want more features, even if they don’t use them. * My note: This is changing however, by companies like 37Signals which release software that has LESS features on purpose.
- Standardization is needed in terms of ‘engineering’ practices, but may be decades out.
- Users foot the cost of applying patches, not the software maker.
I know developers have good intentions and want to make the very best software they can. There are some problems that get in the way of this:
- Businesses have no incentive to be perfect. In fact, being perfect would be stupid. Businesses want to ship the product and start making profit.
- Current programming languages are still full of pitfalls. When C++ was first described to me, the man said it was enough rope to hang yourself 3.5 times. This is true in any language, for any junior programmer, and some senior people never get it. The vast majority of code is written in non-deterministic languages (C++, Java, C#), which have quirks when multi-theading. Only functional languages stand up to multi-threaded execution- the key to harnessing multi-core processor architectures.
- The complexity of dependencies between software systems is just nuts. DLL hell is a thing of the past. Still when it comes to a specific app stack and all the parts that go into it (some perhaps open source?), who knows what will happen when someone half way across the world commits something?
- Let’s not even discuss outsourcing and security.
Awareness of the issues is my only antidote for now. I do my best to bring up these issues to management and make sure they are clear on the situation. Suggestion: frame the situation as an opportunity. The cure is a long time coming and who knows what the catalyst will be?