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?
4 コメント
It takes a long time to deeply learn your tools. Switching means starting over. One of the hardest things in any trade is knowing when upgrading your tools is worth throwing away that experience and how much better they have to be to compensate for the initial drop in productivity.
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.
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.
But if you don't sit down to learn, you will never learn. You will fall into a chicken - egg trap. You will not use a new tool because you don't know if it is any better, and you will not know if it is any better because you did not use it. How to break the cycle?
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.
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.
Is it a big company? Big companies (especially public companies) prefer predictable costs to lower but unexpected costs. They've probably gotten good at estimating work, schedules, hiring, etc using .Net 1.1, so they get the predictability they want. Something that's theoretically better is an ugly question mark for them. Something that's undeniably better (like WCF in your case) has a chance.
Reasons to NOT "rush" to the new:
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.
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.
1, You're not screwing anything up. You're creating some new product from scratch, and resources spent learning a new tool will be resources saved in future projects that use the same tool.
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.
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.
"You talk like my manager. Are you him?"
No. Just someone who has learned how to listen instead of whine.
No. Just someone who has learned how to listen instead of whine.
Experience does not automatically make one able to learn quickly. Knowing how to learn well is a skill itself that many people are bad at.
It's not always like this. Better people exist. But I hear it's common.
It's not always like this. Better people exist. But I hear it's common.