Top 5 “When Good Software Goes Bad” blog posts

2013-04-16

Type “When Good Software Goes Bad” into a search engine and you will find quite a few entries of varying quality and relevance to the actual subject. I know this because a colleague who received an online WGSGB article forwarded by me typed in the exact same phrase and gleefully alerted me to the results. Being a caring sharing kind of guy, I thought you might want a flavour of the results too.

At this point you are more than welcome to jump straight to the Top 5 if you wish. For those of you who like a story, in the interests of context I should explain what drove me to delve into the murky world of WGSGB articles in the first place. I’m a recent convert to the notion of “content curation”, the latest marketing idea designed to help busy people collect digital content relevant to their work and interests from a variety of online sources. Having signed up to Trapit, the best of a mixed bunch which also includes the spectacularly hit and miss service on offer from Google® Alerts, I opened my first Daily Digest from the Palo Alto people.

Trapit uses a three-block format, each block being a self-contained piece of digital content. Each block comes complete with a snappy headline and a colourful image. The overall effect is eye-catching but not overpowering, which meant a trouble-free scan for the content I wanted. It didn’t take long before I found it.

Having read and forwarded the article, I moved on to my other jobs for the day. Meanwhile my colleague had conceived a plan. What if, he wondered, what if this WGSGB article isn’t a one-off and there are more out there lying around on the floor of the Internet like discarded toenail clippings waiting to be swept up by an enterprising writer (OK, that metaphor didn’t last very long; let’s move on).

The rest, as they say, is History: the original article came back to me, followed swiftly by the suggestion that the notion of WGSGB has been around for far longer than we suspected. Sure enough, WGSGB material tumbled out of the Internet and the “Top 5 When Good Software Goes Bad blog posts” blog was born.

Now, having worked my way through the material, it’s time to reveal the Top 5 in reverse order. Cue drum roll:

5. Poor planning might mean having to cut a hole in your roof, or something

Software developers – don’t blame anybody but yourself if your software goes bad. According to the TM Blog “It’s your fault that you’re in this scenario, because you weren’t thinking of where the plumbing was going to end up in order to service the ceiling-sink.”

Full article: When Good Software Goes Bad (Archive)

4. Software has some of the properties of a living thing

So says John Gordon (a pseudonym) in an interesting article which includes thought-provoking comments about the ecosystems which support software but inevitably require new features which could prompt the software to buckle under the weight of expectations. Sadly he spoiled this analysis by banging on about problems he had with some Windows software and I lost interest.

Full article: When Good Software Goes Bad.

3. No leaves on the track this time

In 2011 Jonathan Bloom reported on a software malfunction which knocked out the signalling system on the East Coast Main Line between London and Edinburgh. According to James, “software that should have instructed the backup signalling system to kick in failed to function, causing all signals on the line to default to ‘Red’, halting trains where they stood. The failure left more than 3,000 rail passengers stranded or delayed for more than five hours on a Saturday afternoon.” James’ solution: automated analysis and measurement, which since it’s at the core of what we do, we won’t disagree with.

Full article: When Good Software Goes Bad.

2. Cheerleading for Ada

Scott Kirwin of The Razor spotted an article back in 2008 and he was off. The article (“Crashing Software Poses Flight Danger”, New Scientist, Feb 11, 2008 by Paul Marks) focused on avionics software and went on to talk about Ada, two subjects which are close to our collective heart at Rapita. The thrust of Kirwin’s review and his own article is this: software bugs are too common because programmers are using the wrong programming languages.

Kirwin quotes a “systems engineering consultant in the UK” who reckoned he had the solution: “change the way software is written starting with the languages used. He suggests using computer languages that force the programmer to write unambiguous code such as B-Method and SPARK, instead of more commonly used C and its variants that allow programmers to write vague code that can lead to bugs”.

Commonly known as “strongly typed”, “These languages and their compilers make it difficult for programmers to write ambiguous code by mathematically verifying the code as it is written.” One, of course, is Ada, a language Kirwin believes is unnecessarily restricted to safety-critical situations. Why? Because while C and C++ “may be prone to bugs, it is much cheaper to patch the code than it is to replace it with code that is more robust”.

Full article: When Software Goes Bad.

1. When Good Software Goes Bad: 5 Infamous Incidents

And finally, the granddaddy of WGSGB articles and also the one which kicked off this blog in the first place. Five real world examples of good software going awfully awry in real world companies, including Apple, Intel, Amazon and NASA. There is also a section dedicated to the guy who demonstrated the inadequacies of security measures on early computer networks by creating the first worm. If I were him I would have changed my name by now. Instead, he became a tenured professor in the department of Electrical Engineering and Computer Science at MIT. Under his real name. I suppose there is something to that poacher turned gamekeeper analogy after all.

Full article: http://www.business.com/blog/when-good-software-goes-bad-5-infamous-incidents/