Change is not your enemy, it's your job.
By
Mathias Verraes
Published on 21 July 2011
In a discussion about keeping developers motivated, someone said:
“I also try as hard as I can to isolate our developers […] from out-of-spec change requests”
Sticking to the plan sure allows developers and managers to stay in their comfort zone. The project keeps moving forward, the deadlines are met. But we’re not in the business of meeting deadlines. We’re in the business of building software that delivers value to customers. As the customer gains new insight in what will get the most value, the specs change. And change they will.
The reaction of the software industry has traditionally been to avoid change. Get the customer to sign off on the plan, then stick to it. Make them understand that changes are going to cost them dearly. Shield the developers from change.
The effect is backwards: customers, managers and developers are instilled with a holy fear of change. When, after much resistance, a change becomes inevitable, nobody knows how to deal with it.
Knowing how to cope with change in a software project is a skill like any other, whether it’s atomic refactoring, or big architectural changes, or writing the automated tests that will help you keep your sanity in the process.
Like any skill, you can master it with study and practice. Perhaps the best way to learn how to cope with change in software development, is to deliberately introduce change. It would make an interesting experiment: tell your developers to change things, just to keep them alert and well-trained in the art of change. I don’t know if they will declare you crazy, or if they will be motivated by it. All I know is that I would.