There are patterns, things that developers do when writing code that support testability of code and there are anti-patterns, which are things that developers do that lead to writing code that is difficult to test. As a developer, I’ve found it helpful to become aware of some of these testability patterns and anti-patterns that I frequently see in code.
There are more technical details needed in order to build high-quality software than any one book can cover. Beyond Legacy Code discusses the what and why of good developer practices, so that both developers and the non-developers on our team, like our managers and executives, can understand the reasoning and purpose of these practices to improve their processes. It really helps when developers understand the purpose behind the practices and they use the practices more effectively.
If the techniques and practices of Extreme Programming, such as test-first development and refactoring produced just incremental improvements in code then I’d be sort of so-so about it myself. But creating CLEAN, testable code is clearly the better way to build software. I have firsthand experience helping thousands of developers in companies around the world who now spend less effort developing software that’s more cost-effective to maintain.
Building software with these practices is far less stressful because there are fewer unknowns to deal with and we are able to better meet deadlines because we find fewer surprises that throw our estimates off. We’re focusing on one thing at a time and everything else just sort of fades into the distance so we can do that one thing really, really well.
We’re also building software that can be automatically validated so we can know immediately if there are any problems with it. This helps us elevate testability as a core part of the context for software development and this has deep implications on how we build and maintain code.
Testability is at the core of all good developer practices. We’re still exploring the nature of software in search of a better understanding of the context for software development, and a vital element of context for software must be testability—we must strive to produce testable code.
I recently tweeted this quote from Stanford University Professor Emeritus Donald Knuth: “Programming is the art of telling another human what one wants the computer to do.” I got seventy-six retweets in a few days, but I see too few developers actually following Professor Knuth’s advice.
Managers attempt to answer the question: What are “the right things?” by trying to measure productivity—that old production line manager’s stopwatch—or by imposing more complex schedules even though this often has the opposite effect and ends up demotivating people.
The more process we add the worse it gets because process cannot dictate creativity. And fundamentally we have to recognize that software development is a creative process.
But the truth is that most developers (and people in general) aren’t just looking for ways to game the system and slack off. Far from it! We want to help, to make a difference, yet often we feel it’s impossible to do, so we lower our expectations and fall back on approaches that are less ideal.
What I’ve discovered in my career as a software developer is that information aggregates in specific ways depending on its nature. When we understand the nature of information that we’re modeling then we can model it more accurately and from multiple perspectives and that will give us both understandability and extensibility in the code that we write, which is generally missing in most of the code I see in industry today.
Previous Post: « The Importance of Continuous Integration
Next Post: Pair Programing Paradoxes »