Tips for Managing Technical People – Take Pride in Technical Excellence
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.
Total cost of ownership
The first reason for this is one that you’ll doubtless be aware of, but that bears repeated mention: when costing a piece of software, the most useful cost to look at is the total cost of ownership. Thoughtworks, the international software provider, estimates that 86-94 per cent of software cost is incurred post-release. So, if you spend £100,000 developing a system, there is another £900,000 of costs to come over the remainder of the life of the software.
Good coding practices cost money now. Adding in automated unit testing, spending time on code structure and researching best practice takes time and costs money. But considered over the whole lifetime of the software, these practices save money; they reduce the total cost of ownership. This is of course why they are such hot topics, and why software teams everywhere are focussing more on writing code that is excellent at the detail level.
Pay now, don’t pay later
This is an unarguable benefit. But I think there’s an even stronger one. I think the most dangerous outcome of writing sloppy code in haste to meet a single deadline is that what is done once will get done again. If you accept deadlines that force you to compromise code quality, these compromises will slowly and inexorably creep into your work until they are the norm. Once you’ve established a culture of hastily written, imperfect code, it will take hard work to undo it.
This is a typical ‘pay now or pay later’ choice. Even if it isn’t always expedient, the habit of ‘paying now’ will mean that you reap benefits long into the future.