I think there's a big picture issue here. When you have teams using everything under the sun, one team is using NH another SubSonic, another using a home-baked solution for database access. One is using log4net and another NLog. Then add in some specialty libraries that they picked up along the way. You have a problem in the long run. Maintenance, cross-training, resource replacement all will be very difficult for the company long term. How can you easily reorganize your teams if they are using extremely different toolsets and concepts? Heck, even language standardization. Basically what I'm trying to get at is that a standardized toolset isn't always a bad thing. We sometimes have to remember that when we are being paid to do a job we sometimes have to comply with the laws of the land. Sometimes I don't like it, and you know that I am somebody that will squawk if I can't get my tool of choice. I'm just saying that there's a flipside to the issue that isn't just about command & control.

The brutal truth, is that we are not all "professionals" in the implied definition of the word. Not all developers are as willing or able to expand their repertoire as you and your colleagues are. And most of the senior members aren't really used to working with your caliber of development and skillset. That might sound snarky, but it truly isn't. If I go into a new company and they are even using VSS I'm usually floored. That's just the way it has been in my experience. But the senior developers who set up these policies are usually developers like you or I who've been fighting the battle for too long and are just wore out from explaining themselves over and over and getting constant pushback. So when they get into a position of authority they lay down the law. Along comes a rockstar and they don't exactly know how to react except to use the approach they've used for years. Dogma. Just my opinion.

@Derik Maybe. There may be a standard stack but that doesn't mean you have to use all of it. Back when I was working for my father in his truck shop we had a huge toolbox full of tools. All work was done from that toolbox from fixing the roof to repairing the vehicles. We didn't just use the same hammer for everything, we had several hammers for different jobs. One standard toolset isn't entirely an evil thing.

I think you taking what was said a bit too literal.  That, or you were irked by the "a *real* shop" line because it smacks of elitism (which it does).

If it read something like:

"A good software shop isn't going to have umpteen different libraries anyway - they'll have a limited set of libraries to choose from for every project."

or something to that effect, I don't think you'd take issue with it.

As Michael pointed out, consistency within a development department is so important because more often than not the person maintaining a product is not the one who built it.

I could not have put it better myself. Too bad people will always think "their way" is the best way and will still follow their ivory tower mentality.

Derik,

I do think you have a point, I'm pretty sure we've all worked with the kind of person who always uses qualifying statements like "I have 20 years experience!" when they are asked questions about their horrible code. :)

I agree with Mr. Hall. It all depends on how your organization defines "team".

We have an in-house applications development department that primarily deals in WinForms, a web development department, and a bioinformatics department. Each determines and uses its own set of tools. There is some lateral movement of developers, but generally one stays in one's own department.

Within a given department (like AppDev, where I work), there are multiple project teams operating at any given time. After a sprint, a developer may be assigned to another team. It would greatly increase training requirements if every team were allowed to pick their own persistence framework, logging framework, UI component toolkits, or even .NET language. Learning a new problem domain is enough of a challenge.

And then there's the additional challenge of supporting multiple frameworks in the field...

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Pingback from  igorbrejc.net » Fresh Catch For March 22nd

I agree with your post in part.  My general strategy has been to say for organizational consistency that there should be a pseudo-standard "stack" (e.g. let's not have everyone in the entire department have 15 different ways to solve data access).  That being said, every project has their own individual needs and thus should be capable of arguing cogently to justify why they would need to deviate (I had this experience in reverse several years ago when I was asked to justify why my $20M+ project was going to be using NHibernate vs. dataset-driven designs).  

As for "Let software developers do what they do.. Create Business Value through solving business problems.  Only way this can happen is if each team has the flexibility to make its own decisions."

You'd be surprised at how many developers spend more of their time whining about tool stacks vs. actually delivering real business value.  I'm not for mandating anything, but I also wouldn't want there to be a repetitive spiral on the team trying to repeatedly refresh/investigate new technologies at the expense of, you know, actually getting shit done.  And I've seen that sort of intellectual masturbation happen too many times, or on too many blogs, even!  ;)

Buying cheap soma free delivery. Cheap soma.