The cost of Change

Decision Time:

1. Continue working the way we were, using the tools we know and their limitations OR
2. Learn the new tool/technology, invest time and effort in migrating to it and train the team to use the new tool

I'm sure many development managers have faced such a question. More often than not, we choose to go with option #1. The usual justification is -

It's tried and tested and WE DON"T HAVE THE TIME TO JERK-AROUND with the new stuff. We need to build the new features and focus on our backlogs!

The only problem with the above is that while you are considering the Cost of Changing, you are usually completely disregarding the Cost of NOT Changing. You'll never know what you are missing out on unless you try it out.

We've be considering switching from subversion to git since quite some time. Evey time I've been delaying it thinking that is it really important? Doesn't subversion mostly cut-it? It's not really hurting is it? Nah... let's stick with it, there's too much on our plate as it is.

Last month, we finally switched and I've been cursing myself for not doing it earlier. It's a truly liberating experience when you can work on a new feature having full confidence of being able switch back to your main code base if you needed to. The ease of merging other developers' branches into the main code has helped me to delegate even more.

What I take away from this is that always realize that there is a cost of not changing. This can't really be determined. The only way to decide is to use your gut feeling.