14 August 2014, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
Pragmatism or sloppiness?
From a developer’s point of view, customers (external or elsewhere within the business) are always forcing them into compromises. They want another week to finish a feature properly – the customer wants to ship now; they want to use a new technology as an experiment – the customer wants to use a well-established standard tech to ensure that they can maintain the codebase going forwards.
Pragmatism has many benefits. Indeed, it’s not possible to run a business without it. At a more detailed level, however, ‘pragmatism’ is often simply a euphemism for sloppy work. While sometimes it makes sense to leave large features that can be implemented later to a future sprint, or to choose a simpler implementation now that may have to be rewritten later, it’s never correct, in my view, to ‘save time’ by writing poorly documented, poorly structured or poorly tested code.
15 May 2013, by David Simons
In 2003, the space shuttle Columbia embarked on its 28th mission. During many of the previous launches, something broke off the body of the rocket. No major damage was caused, so it was dealt with as a minor issue, being fixed and forgotten about. Soon it became a matter of process that something flew off. It wasn’t as expected, but it was tolerable. But this time, a piece of foam insulation broke off and damaged its thermal protection system.
Two weeks later, Columbia disintegrated during re-entry into the Earth’s atmosphere. The crew of seven all died.
Fortunately, most of the software we write doesn’t have life or death consequences, however there are still lessons that the software industry can learn from this, as I found out when attending the QCon talk “The Inevitability of Failure.”