Ask YC: Resistance to the new.
I noticed a trend on my company, and I wish to know if this is standard all around. I am a unexperienced coder, I have a tad more than an year on software development field as a professional. I noticed that people that are far more experienced than I am are quite resistant to change or to try anything new. Not many months ago I had a discussion with my manager about being allowed to use .NET 3.5 because the company was still using .NET 1.1 due to the fact that "the company" did not have enough time to analyze how .NET 2.0 "worked" and couldn't understand the impact of the change, much less .NET 2.5. I would still be developping in .NET 1.1 wasn't for the WCF that comes as part of .NET 3.5 and would cut a lot of development time because the company decided to make the software using SOA. Is it always like this? Why is it that the ones that could learn quicker due to their greater experience are the ones less willing to learn?
7 comments
[ 2761 ms ] story [ 581 ms ] threadIt's not always like this. Better people exist. But I hear it's common.
Hackers are optimists; managers are pessimists. We tend to err on the side of cool toys; they tend to err on the side of avoiding catastrophe.
By the way, it DOES take a long time to deeply learn your tools, but it takes a very short time to learn them enough to reach the same level of productivity than the older one, unless it is a complete shift of paradigm. This is specially true when you are moving to newer versions of the same programs, as long as some backward compatibility is kept, you will be not starting from scratch.
1. The current runs perfectly. Why spend any resources to risk screwing that up?
2. New releases often introduce new bugs / problems. (Vista, heh heh)
3. ANY change requires SOME resources. How much can you spare?
4. Often, the "latest, greatest" technology turns out NOT to be. Many people prefer to wait to see how adoption goes.
5. Change often requires education. Have time for that right now?
6. <add your own>
Not making a judgment either way. Just pointing out a few things off the top of my head that concern shops already overloaded.
2, And old releases have bugs that will hardly be fixed because the support has been dropped. Follow the six month rule, and then, if you find more bugs, report. It is a lot more likely that the bugs in a new version will be fixed, and quickly, than in an old version.
3, The amount of resources the change will save due to its improvements. I am not saying it will always net positive, but it will also not net negativly always, so it is worth a study. Dismissing because "We don't know" is not a valid excuse, or should not be.
4, Once more, use the six months rule. Anything that is still a hype after six months in a fast paced market like IT is worth a look only for this merit.
5, Again, it depends on how much time the change will save BOTH in the current project and in future ones. A mistake always made is to consider only the current project as time spent. This is unfair and will lead to biased results that will cause the change to be refused nearly always.
6, You talk like my manager. Are you him?
I know you are not making any judgement. You are telling me what you have heard before, probably when faced with the same situation. Problem is, when faced with counter arguments the final answer is "We don't know" or "We don't want to". It is a lose lose situation.
No. Just someone who has learned how to listen instead of whine.