2025 Public Training Schedule
January 14 – 17, 2025 – 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
- March 25, 2020
- Implement the Design Last
One of the most important characteristics that I find senior developers have is the ability to change their minds and let go of an existing design when it no longer serves its purpose. What I find time and time again is that developers become attached to the current design even in the face of changing requirements that invalidate that design.
Simply being willing the change your mind is a vital skill to have when doing emergent design because emergent design means that you are changing your design as you go. In order to do that, we have to let go of our current design in order to come up with something better.
All this changing of design in existing code might sound like it’s dangerous or inefficient but when we understand refactoring, design patterns, and have good regression tests that support refactoring then we can do it safely and efficiently.
We don’t want to get too attached to any design because things change. When requirements change, very often it implies that the design has to change as well. This is why I don’t get too attached to design and I always try to keep in mind what my options are that will allow me to go from an existing design to something else that would be more appropriate in the light of new or changing requirements.
One of my favorite quotes from one of my favorite writers, Stephen King, is “murder your darlings.” By this what I believe he meant was that we shouldn’t be too attached to anything in particular. Sometimes as a writer I find that I get particularly attached to a passage that I’ve written. Now when I do that I often delete that passage and start over again. I find that trying to force-fit everything else around a passage that I love to be difficult and can make my writing appear awkward.
When I write I spend a good deal of time and energy outlining because it allows me to immerse myself in the context of what I want to say without having to become attached to any particular way of saying it. I try to do the same thing when I code. I try to write software in such a way that I can easily refactor it in the future, as I learn more. By doing this, I recognize that I can change my design at any point that’s appropriate and so I don’t have to worry about getting it right upfront.
I think that a lot of developers think that they have to get their design right in the beginning when they hardly understand the problem to start with. I used to believe that but I don’t believe it anymore. Today I find that building systems based upon the customer’s priorities and delivering work in progress are a highly effective way of producing valuable software.
As I learned more and more about how to do emergent design well and the power of refactoring code, it allows me to go from one design to another design with minimal risk, and I begin to recognize that it doesn’t matter where I start with the design—what matters is where I end up. And having the skills to refactor my designs gives me the freedom to end up wherever I need to.
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: « Focus on Code Quality
Next Post: Practice Good Development Habits »