2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 1, 2017
- Bits and Pieces
What does changeability mean in the context of software? Software is soft so shouldn’t it all be changeable?
Not exactly.
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.
An 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!
Previous Post: « An Object Model
Next Post: Early Automation Experiences »