Small Things Matter

Story of the Concorde

On July 25th, 2000, flight 4590 crashed. It was the first, and only, crash of the famed Concorde. Eventually, it would lead to retirement for the amazing aircraft. Investigators spent countless hours poring over the wreckage, and placed blame on a piece of runway debris that slashed the tire. A piece of that tire struck one of the fuel tanks, causing it to rupture and the plane caught fire. Case closed, right? Not so fast.

Surely a small piece of runway debris shouldn’t bring down a commercial airliner! As it turns out, there is quite a bit of contention among experts surrounding other factors that may have contributed to the crash. Some argue that it was a complex chain of events, all coming together, that brought down the aircraft. The plane was missing a spacer between the two wheels, had too much fuel in the tank, attempted to takeoff in unstable conditions, and was overweight. The flight was also delayed, causing angst among the flight crew. Finally, a required daily runway inspection was not performed.

Perhaps, if the runway inspection had been performed, the piece of debris would have been spotted. Or had the aircraft not been overfueled, the piece of tire may not have caused an increase in fuel tank pressure that some say caused the tank to burst. Had the spacer been installed, it’s possible the tire would have never burst. A series of small events, each contributing in their own way, to the fatal crash.

No Matter How Small

The story reminds me of the importance of attention to detail in software development. Of how the aggregate of all of the small, seemingly insignificant decisions we make on a continuous basis can have long-term consequences on the future of the software system. Possibly even your organization. Every time you design a class, define a variable, write a test, create a package, build a module, modify a method, or make a design decision, you are affecting the future of your system in some unsuspecting way.

What may seem insignificant today, can have a detrimental affect tomorrow. Really, there are no small, insignificant decisions in software development. I’m reminded of how important it is to make conscious decisions that are given careful thought, no matter how small. It also reminded me of a poem on build automation and continuous integration that I read a while back on the Test Early blog.


For want of a build, a test case was not executed
For want of test case, a defect was not detected
For want of a defect report, a bad release was promoted
For want of a good release, a strategic customer was lost
For want of a customer, a development team was reduced
For want of developers, a product stagnated
For want of a product, a company was lost
And all for the want of a build…

5 thoughts on “Small Things Matter

  1. Kirk,

    You may be interested in the following book – Normal Accidents: Living with High-Risk Technologies – by Charles Perrow.

    Catastrophic failure is usually the result of a set of correlated failures, which individually seem of little significance. In complex systems such seemingly minor events can / frequently do / cascade.

    A fundamental reason to adopt Crash Only / ROC software design.



  2. “Really, there are no small, insignificant decisions in software development. I’m reminded of how important it is to make conscious decisions that are given careful thought, no matter how small”. Great article Kirk, you hit the nail on the head squarely with that one.

    As a contractor and consultant you soon realise how rare conscious design thought is in software development. I shake my head in wonder every time I hear a debate of methodologies and design patterns when I realise as an industry we still haven’t learnt to master (or effectively teach and promote) the basics of thoughtful design.

  3. Software tends to look exactly like the company that produces it. Companies interested in short-term, quarterly profits tend to produce everything (not just software) that reflect their objectives: short-term, cost-cutting thinking and a lack of long-term strategic objectives. It’s a wonder that some companies are even able to produce functional software at all.

Leave a Reply

Your email address will not be published.