As you can see from my last seven blog posts, doing emergent design is not for beginners. Doing emergent design is an advanced development practice.
But it’s not enough to know about good development principles and practices. It’s not enough to know about design patterns. We have to use them. We have to apply them. We have to understand them so that we can get benefit from them.
I think that many developers and their managers are under the false impression that taking shortcuts will save them time. I find that shortcuts and cutting corners, especially in terms of software quality, won’t save us time but in fact, costs us both in the long-term and often also in the short term. That doesn’t mean that I don’t make compromises because I have to if I want to stay in business but learning how to make the right trade-offs is critically important.
There are many compromises that I will make on a project in many design decisions that I will give in on but I do have some basic nonnegotiable’s. I always write code while paying attention to code quality. That’s non-negotiable for me. When I see that I’m writing some behavior that I have written before, I’ll take the time to put it in a single place and call it from both places. When I find that the behavior of a class starts to exceed its single responsibility then I’ll take the time to split the class out into multiple classes, each with its own responsibility. I do these things habitually because they save me time, not just in the long run but also in the short term.
Here’s what I’ve learned from studying thousands of professional software developers: It’s not the practices that a developer uses that makes them efficient. What makes a developer efficient are the practices that they’re used to.
Developers who are comfortable with good development habits that produce high-quality code can do so very rapidly. Developers who have poor practices and are used to turning out buggy code can typically do those practices pretty quickly as well. It’s not the practices themselves that speed us up or slow us down, it’s how familiar we are with doing them.
The key is to find good developer practices that support us in writing high quality, maintainable code and making those the practices the ones we are most familiar with. If we can do that then we will build high-quality software rapidly.
I no longer ask myself when I’m coding whether I should cut corners on code quality or not. I always write software that’s CLEAN. I no longer question whether I should do this and because I don’t need to question myself, I can be really fast. I often find that it’s not the technique that slows us down but rather questioning ourselves whether we should apply the technique in any particular situation that slows us down.
Making something a habit is simply when we cease to question it. We do this because it’s more convenient to just do the thing than to keep questioning it. Instilling good habits can be very helpful and knowing the process by which things become a habit can also help drive us to create good habits that support us in building quality code, which will help us more easily emerge designs.
Note: This blog post is based on one of the “Seven Strategies…” sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
Previous Post: « Be Merciless
Next Post: Why Practice 9: Refactor Legacy Code »