I don’t trust change. I know change is what we do, it’s why people need new software to do things they couldn’t do before, to sweep away the cobwebs and start everything anew. To change. For the better.
The better what? Faster, more efficient, more user friendly. “Just better”. “An improvement”. “The new shiny”. “Make it cool”.
Great, can you write me a requirement for that, or some acceptance criteria?
“We’ll know it when we see it.”
But how will we know?
“It doesn’t matter. We’ll know.”
And when you come back and say it doesn’t have enough “zing” or “pizazz” or isn’t “cool” or “new” enough?
“Well then, it shows you didn’t listen to us.”
A change for the better?
If you want to change, you should know why. What will the users notice? What pain will it take away? What will it allow you to do that you couldn’t do before?
Those are questions I can pick away at, questions with an answer where I can measure something tangible. I can change the time it takes to do something, I can change a system to do something new, and I can show you exactly what the change looks like.
A change without a diff is a break.
If you don’t know why you’re making a change, the chances are, you’re making the wrong change, and you won’t know when the change is done. Make a small improvement, or a big one, but know why. If you can’t articulate the difference between the present reality and the desired future, all I can tell you is that the change will break. It might be beneficial, it might not, but there will be no way to trace from now to the future, and no way to know if anything has improved.
The best change may be no change
We love writing software, coming up with new ideas, new approaches. We want the new shiny. But that doesn’t mean it will do us, or our customers, any good. Angular.js makes it much easier to write web apps a certain way, but is that the type of web app that most suits your customer, and do they really need a web app at all? Is a web page easier for them?
And maybe what needs to change isn’t the software. Maybe there is a process that people have forgotten that will fix the problems, maybe they’re solving the wrong problem.
Software isn’t always the answer, and neither is change.
When to embrace change.
Change when things cause you pain. Subversion makes branching and merging painful. If that’s a problem for you, try git or mercurial. Manipulating the DOM from a callback is painful. If that’s a problem for you, try Angular or another framework. If they’re not causing you pain, chances are something else is, go change that first.
Change when there’s a functionality gap. When you’re chasing a new regulations, new APIs, new competitors, or new customers. And make sure that functionality does something to help close that gap. You might have a few ideas, so pretotype and prototype them first, make the change as small as possible, and build on it, because a small change is easier to throw away, physically and psychologically.
But don’t trust it, until you know where you want the change to take you, and you have a way to check you’re on the right path.