Refactoring whizz: Good software shouldn't cost the earth – it's actually cheaper to build
Repeat after me, better software costs less...
Interview ThoughtWorks chief scientist Martin Fowler has written about the curious inverse relationship between quality and cost in the field of software development.
The user cannot distinguish between good or bad internal design simply by observing the user interface or the features, he observed. This means that poor-quality software appears more productive in the early stages, since functionality is delivered more quickly. In just a few weeks, though, this changes.
"Progress is rapid initially, but as time goes on it gets harder to add new features," he writes on his personal website. "Even small changes require programmers to understand large areas of code, code that's difficult to understand. When they make changes, unexpected breakages occur, leading to long test times and defects that need to be fixed."
It follows that maintaining high quality both internally and externally enables increased productivity and lower cost, but this runs counter to the human instinct that high quality costs more.
"It's this innate intuitive sense that we have, that more quality means more expense," Fowler tells The Reg. "We see it in all aspects of our life, usually. If you want something nicer you pay more for it. That naturally ties into our thinking about software.
"That mindset is deeply there. People say, 'If you’re a startup you've got to go fast, you can't afford to have quality code.' Well, it depends on your time horizon. My view is that if you're building something for more than a couple of months, then you are actually going to go slower if you have that attitude.
"You could draw parallels with [Daniel] Kahneman's [book] Thinking, Fast and Slow. The 'thinking fast' part of ourselves says quality costs more. We have to make the mental effort to realise that it's a bad metaphor for what's going on.
"You couple that with project managers and customers who don't know anything about building software and that is only reinforced. Then you also throw in the fact that so many people in the programming workforce have not had the opportunity to work in a quality software environment so they have no idea what they're missing."
Refactor your mindset
When asked what can be done to fix the problem, Fowler says: "Recognise that that mindset is incorrect. That's the most important shift, because that drives so many other things. Then it's paying attention to the things that are slowing us down and paying attention to fixing those on a gradual basis.
"It also means investing in the skills level of the team. And making sure they have the skills to understand what good modular design is, what role testing plays, the importance of continuous delivery, and how to write clear code, and have the team reflect on what code is clear to them and what code is not.
"These are all gradual steps, this is not something you can fix in a couple of months by buying a fancy tool or something. But we've seen it can have an effect, you can have teams that will get there."
Fowler also discusses the problem of "cruft", caused by changes in direction as a software project evolves. Cruft is inevitable, he wrote.
"Software projects are always creating something novel. We hardly ever find ourselves working on a well-understood problem that's been solved before. Naturally we learn most about the problem as we're building the solution, so it's common for me to hear that teams only really best understand what the architecture of their software should be after they've spent a year or so building it. Even the best teams will have cruft in their software."
He adds that the notion that software which changes frequently is less reliable is false. Referencing the DORA (DevOps Research and Development) State of DevOps 2018 report, he notes: "Elite software teams update production code many times a day, pushing code changes from development to production in less than an hour. As they do this, their change failure rate is significantly lower than slower organisations [and] they recover from errors much more quickly.
"Countless times I've talked to development teams who say 'they (management) won't let us write good quality code because it takes too long'... The annoying thing is that the resulting crufty code both makes developers' life harder, and costs the customer money."
Enough to convince management that is it worth getting this right?®