2024 Public Training Schedule
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 9, 2016 ( 1 comments )
- Implement the Design Last
One characteristic I consistently see among outstanding software developers is that they’re not afraid to change their minds, to change their approach, or to change their designs.
In Agile we start building right away before we have all the requirements nailed down and we let new requirements emerge as we’re building. To those unfamiliar with Agile, it may seem inefficient or even reckless to write code without seeing all the requirements first. You wouldn’t build the first floor of a building without considering the rest of the structure. But building software and building buildings are very different from each other.
New requirements can pull us in new directions and show us that our current design is inadequate. This is actually a good thing because we only want to build for what we currently know. So what do we do when we know more? The answer is that we change our minds.
Refactoring is a disciplined way of changing your mind, of changing from one design to another design that’s more appropriate for your current situation. Refactorings are code transformations that let you safely go from one design to another design. This is how we should build software: through emerging designs as we go.
It was Martin Fowler who turned the idea of refactoring into a true discipline when he published his book, Refactoring: Improving the Design of Existing Code in 1999. This book is a catalogue of code transformations that allow you to go from one design to another design and improve your code in some way without changing its behavior. Since its publication, Fowler’s book has become a critical resource for Agile developers.
The interesting thing about refactoring is that most refactorings are pretty straightforward and don’t require a lot of effort. Contrary to what some people believe, though refactoring legacy code may be difficult if it’s in a poor state, refactoring your own code from one design to another design is much easier.
This is important to note because it means we can change our minds and change our designs when we know more, and do it without paying a huge price. When developers understand this, it helps give us a level of freedom we hadn’t known before. No longer do we have to get it right the first time, which is an enormous stressor. We can start with a very simple design, and as we learn more we can refactor to a more appropriate design.
This turns out to be a highly efficient and effective way to build software. It not only builds software for the right purposes, it also helps us build software that’s flexible and able to change as new needs emerge.
{1 Comments }
Previous Post: « Integrate Frequently
Next Post: Collaborate »
Hi ToBeAgile,
I really liked how you expressed your thoughts about changing nature of software development in Agile and agree on most of the part. However, there are some points which I think are not accurate. For instance, in the second last paragraph you say:
“This is important to note because it means we can change our minds and change our designs when we know more, and do it without paying a huge price. When developers understand this, it helps give us a level of freedom we hadn’t known before. No longer do we have to get it right the first time, which is an enormous stressor. We can start with a very simple design, and as we learn more we can refactor to a more appropriate design.”
Although it gives developers a freedom, at the same time it can contribute to making them lazy or careless that they will write or start supporting bad code just because of thought that it will be refactored at some point of time. This can also result in the proliferation of technical debt.
On the other hand, refactoring an application architecture frequently is also not good and mean that your team lacks of architectural skills required.
It could be helpful in some cases to start with simple design and refactor later on, but it’s always good to see or at least guess the future picture and design solution to support all future changes. The design should be open to extension in a way that can accept changes being introduced instead of requiring a whole re-write of design.
Again, these are my personal thoughts and not guaranteed to be 100% correct, but at least something to consider about.
Thanks,
Harsh Raval