- Continue working the way we were, using the tools we know and their limitations OR
- Learn the new tool/technology, invest time and effort in migrating to it and train the team to use the new tool
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.
2 comments:
Thanks. I've been holding off on git too. I'm going to switch over now... (someday anyway) :)
Discovering something like that can sometimes bring a tear to the eye. I think it sometimes requires having gone on the longer road before, though, before being ready to appreciate or even make use of the new approach.
Post a Comment