Software should be able to be changed. But it can only do so when it's written well. Read on to get one Agile expert's opinion on the matter.
Join the DZone community and get the full member experience.Join For Free
What does changeability mean in the context of software? Software is soft so shouldn't it all be changeable?
It turns out we have to build changeability into code, but this is rarely done. To do this we have to understand the nature of software and the nature of change.
Software doesn't behave like physical things. Software is a virtual thing and subject to the laws of the virtual universe, which are different from the laws of the physical universe. The lifecycle of virtual things is different from the lifecycle of physical things as well.
We talked about "bit rot" but of course, bits don't rot. Software doesn't change on its own. In fact, it's one of the few things in the universe that doesn't decay. Relative to the rest of the world, which is in a constant state of change, it only appears as if software is rotting or going stale. Our needs are ever-changing and in order to keep up with those ever-changing needs we have to write changeable software.
A NIST study showed that 80% of the cost of software happens after the initial release. On average it costs half as much to build software as it costs to fix bugs that escaped into production after release. The reason it costs so much to maintain and extend software is that we don't write changeable code. We create un-cohesive classes and methods that are concretely coupled, leak implementation details, produce unwanted side effects, and repeat code found in other places. In short, we write dirty code.
I've written a lot about what I call CLEAN code qualities like cohesion, loose coupling, encapsulation, assertiveness, and non-redundancy. These five code qualities underlie all good software and help make code more changeable. Likewise, "Uncle Bob" Martin's SOLID principles also support changeability. The disciplines that comprise Extreme Programming (XP), like test-first development and refactoring, are all about supporting changeable code.
Why? Because code needs to change but changing it can cost a small fortune. But if we write code that supports changeability, when the inevitable happens and code needs to change, we can handle it with less complication.
The biggest impediments to changeable code, aside from code that lacks CLEAN code qualities and SOLID principles, is code that's not supported by unit tests. This code is hard to change because there's no fast way to validate that it works after changes are made.
Bad developer practices are rampant in our industry and there's very little consensus on the "right" way to do things. This is because there is no one right way to do things. There are many equally valid ways to approach writing software, but we need touch points that let us build software the way we want to but still allow us to easily integrate new features and refactoring into the system.
I believe we already have a solution to this problem and it's called test driven development. But not just any test-driven development, the kind of test-driven development that comes from using tests as specifications. And that is the subject of my next couple of posts so stay tuned!
Published at DZone with permission of David Bernstein , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.