The Will to Change

Posted by indomitablehef | Filed under Refactoring

It’s that time of year, again: when I start writing down goals and trying to plan for the year to come. One of my professional goals this year is to be more “community oriented”. For me, that means blogging, being involved with local developer groups (like Nashville Alt.Net and the Geek Social, to start), and OSS. I’m planning to release my SQL TDD framework very soon, and hoping to contribute to at least one other Open Source project during the coming year. So, if all goes well, you should start seeing more posts from me here in the future, starting now.

Then he showed these men of will what will really was. - Kaiser Soze

Awhile back, I read Ayende’s post on Reducing The Cost Of Change. It made a huge impression on me, and has changed the way I look at refactoring and change ever since.

The gist of it is this: We have all kinds of tools and practices designed to reduce the cost of change: TDD, Iterative Development, the Single Responsibility Principle…and the list goes on and on and on. Embracing Agile, we embrace the idea that change is inevitable, and we do our best to make it as painless as possible in everything we do along the way.

But when it comes time to change, there’s no substitute for the will to change:

But it is neither the tools nor the practices that actually enable change. They are not even significantly responsible for reducing the cost of change. Beyond anything else, it is the will of the team to accept the pain of making the change and actually doing this.

How many times have I avoided making a change because it seemed to painful, too difficult? And how many of those cases do I look back on and see that when I finally did make the change, it turned out not to be such a big deal after all? Even when it was a big deal, the worst part of the experience was usually the anticipation and and dread I experienced leading up to the change, rather than the change itself.

When you take this to heart, it can change the way you approach things from the very start, as I am beginning to see. You develop the courage to simply try things, knowing that you will have the will to change it later on.
Quoting Ayende again:

That mindset, at least for me, starts from the first line of code. I treat each piece of the project as utterly disposable. Since I don’t really care how each individual piece works, I am able to roughly sketch a fair amount of the application very rapidly, and then focus on each of the items in isolation, and replace that with a much better implementation. I think that I stated before that I tend to rewrite most of my application core at least two or three times before I am happy with them.

So thanks, Ayende. This short little post has been an “ah-hah!” moment for me, and I think I’ll always be a better developer because of it.