Standardizing on VB.Net

by Michael McClenaghan 2004-10-26

I dropped the hammer today at work regarding our emerging dual-language standard.  For about 6 months now, we've had one developer that was under very tight deadlines and was more comfortable working with C#.  Our current standard is VB.Net, but our architecture for GeoExplorer v3 should support modules in any .Net language, so I figured that this was a good opportunity to test that theory.  That's where the problems started.

After the project with tight deadlines was over, I didn't step in quick enough to ensure that the VB.Net standard was followed for subsequent projects.  Sure enough, this developer ended up being the lead in a few other projects and implemented the code in C#.  Of course, there were other developers on these projects, so now they had to code in C#.

I'm still not very good at laying down the law and telling developers the way it has to be rather than asking for opinions and going for a "majority rules" kind of solution.  But, this problem has been gnawing away at me for awhile.  I truly have nothing against C#, but there is absolutely no reason to switch to it.  I also believe that having two official languages will lead to nothing but trouble - just look at Quebec!

Anyways, I talked to the developers in person and told them the way it was going to be.  There was absolutely no problems except for the primary developer in question.  But, I knew there would be problems there.  Oh well.  What's that line about cracked eggs and an omelette?

blog comments powered by Disqus