When I started developing software professionally over a decade ago I would readily diverge from company standards at a whim to use a new language, style of coding, favorite editor/IDE, libraries, different build process, etc… Mainly because I wanted to be using new stuff or because I thought a new tool or approach was better than the outdated company standard approach. Once I started managing engineering though I quickly began to realize that this type of whimsical divergence has a very real orgranizational cost associated with it both on the systems as well as the software front.
Here’s a real world example that you see at many organizations. Say I have 2 web projects at my company such as an intranet site and a public website. If I put two groups of programmers to work on them, within a week both projects will have very different approaches and tools for build processes, deployment, dependency management, app server, database, possibly language, etc… All of this lack of standards has a very real dollar and cents cost to the company since it’s now more costly for one person to move from project to project not to mention the breadth of knowledge required.
So why don’t organizations standardize on language, build process, coding style, package naming, dependency management, app server, IDE, etc…? Because people can’t agree on the “best” or most “correct” software, it’s a very heated and often personal subject and that’s our (myself included) biggest problem. Consistency is far more important for an organization than “correctness” or using the “best” software. Organizational consistency promotes depth of knowledge rather than requiring an extreme breadth of knowledge.
The gains you may see on your project using Ruby or Python will pale in comparison to the long term maintenance costs the organization will incur if it has 5 software products in 5 different languages. Now, more than ever I believe in strict standards in an organization even down to dictating which IDE is used and using checkstyle to enforce consistent coding standards. It allows developers to quickly move between projects because they can start by understanding the code rather than having to learn a whole new set of tools.
This begs the question though of how an organization can evolve if they set standards and discourage divergence from those standards. My answer to that is that it needs to happen selectively through pilot projects and when successful needs to be adopted and gradually rolled out company wide or abondoned. Standards also need to be reviewed regularly by sharp people who will be implementing those standards. You need buyin from the very top for this type of approach rather than bringing new stuff in under the radar but in the long run it’ll save the company money.