Code Transformations

A lot of poor designs can be attributed to sticking with an existing design as changing requirements show us the need for a better one. Oftentimes, an initial design is just a stab in the dark. We might not know enough to make an informed decision but we have to get something done, so we do what Agile says and we code up the behavior that we need right now and not worry about future requirements.

For most teams, the problem comes when they start to enhance that behavior and go back into the code to extend it. Now they're asking the system to do something that it couldn't do before and, instead of redesigning a feature to accommodate the new behavior, developers might try to hack in the new behavior while minimally impacting the existing design. But this can degrade the quality of the code when done over and over again in a system.

What if we don't have to get it right the first time? What if we could start off with a crappy design but improve it over time as we learned more about how the design should be and what behaviors it should be able to accommodate?

It turns out that often a "learn as you go" approach is more efficient and effective than the "figure it all out upfront" approach. It turns out that most of the time, in order to go from one design to another design in code requires a minimal effort. Code refactoring is a reliable, safe and effective way of transforming the design of software, which we typically need to do in order to accommodate new features.

We often stick with an existing design because it's what we know but this is something that's going to have to change in our industry. We have to be willing to change our designs in light of new information and pay off technical debt when we do it.

The book Refactoring: Improving the Design of Existing Code by Martin Fowler is an essential text for all developers. It teaches us about common transformations in code that allow us to clean up existing software so that it's more extensible and reliable.

Reading this book and learning how to refactor code has been very freeing for me. It means I don't have to get the design right the first time. In Agile, that's rarely possible anyway because we often start building software without a complete set of requirements so we're always dealing with unknowns. Knowing what it takes to go from one design to another in software means that we don't have to get it right the first time. It means we can start out with the wrong design and change it later without paying a high price.

So, our initial design doesn't really matter, as long as we can change it later to a better design without a lot of rework. This takes the pressure off of us to get it right up front and is actually a very efficient way of building software. It means that we can emerge features as they're needed and this turns out to be a highly effective way of building many kinds of software systems.