Change Your Mind, Again

When I was a kid I was told that it was a woman’s prerogative to change her mind. For some people, though, changing your mind can be seen as wishy-washy. We like to stand by what we say. We like to be right.

But giving yourself the freedom to change your mind is one of the key characteristics of all great designers.

Assuming we can’t accurately predict the future—and we can’t—we must find ways of accommodating change when it inevitably happens. This is entirely possible if we make maintainability and changeability of our code a priority. But most developers build software that’s intertwined with itself and is hard to independently test and extend. We overuse inheritance, write concrete implementations, construct the services we use… and these things make it difficult to modularize our code.

But if we pay attention to good design principles and practices, we should be able to change our minds and refactor our designs without having to pay a high price later. This is the whole purpose of good object-oriented software. It’s not just to make the computer do something today, it’s to create a model that’s understandable and reliable so that it can be understood in the future and be adapted to the changing needs of the user. Building software so that it remains an asset not just right now but far into the future can be done through understanding what’s being modeled and modeling it in such a way as to reflect that understanding. This allows others to see how to extend the design naturally.

Being willing to change your mind means that you can start anywhere and refine as you go. It means you don’t need to figure it all out up front before you get started, and it turns out that figuring things out as you go can be much more efficient. The key to being able to change your mind effectively in software development is to know how to refactor code.

Usually, refactoring code from one design to another design is simply a matter of repackaging the code. So refactoring a design to accommodate new features does not usually require a lot of extra work. There are ways to refactor code safely when it’s under automated tests. Most of the time, it’s quite straightforward to refactor from one design to another, making it easy to change your mind.

In Agile, we go into iterations with unknowns. We learn as we go, but sometimes we get blocked. Sometimes the problem appears to have one solution but then as we get new requirements we realize we need a more flexible solution. Once we know that, we can refactor our design into something better. We don’t have to make all the right decisions up front as long as we’re willing to go back and improve our designs in the light of new information.

Changing your mind tends to mean you’ve discovered a better solution—take advantage of it!