It’s been a bit longer than I wanted between posts – side effect of coming off of a vacation and going directly into a new job. Sorry. I’ll try to be more consistent, moving forward.
The idea of maintaining a single technology stack in a development shop is quite appealing. If everyone knows the same programming language (the thinking goes), the same web framework, the same RDBMS and so forth, then life would be better. Business really likes this kind of thinking. It promises efficiencies of scale, reduced training costs, and easily replaceable employees. This kind of “one true technology” approach is the foundational philosophy of corporate darlings Java and .NET. Once you have the organization standardized on the tech, it is promised, then every part will play nicely with every other part, critical dependencies (such as employees) will be reduced, and the whole “what are we doing about technology” question just goes away.
Now, of course I support operational efficiencies, reducing training costs (well, to an extent: I view training as an investment), and so forth, but I think that the idea of “one true stack”, especially in service-oriented tech shops like web agencies, is a pipe dream. The advantages of standardizing an entire company on a single tech stack are outweighed by the disadvantages.
Before I get into that, however, I want to introduce the idea of a “jealous” technology. A jealous technology tries to take over as many aspects of the stack as possible; mandating a specific component at each level. Some technologies are more “jealous” than others. Microsoft is notoriously jealous: the Microsoft web framework, ASP.NET, really wants to be deployed on the Microsoft web server: IIS, on the Microsoft operating system: Windows, backed by the Microsoft RDBMS: SQL Server. Other combinations (yes, I know about Mono) simply don’t work as well. And, on the other hand, Windows is something of a second-class deployment platform for most other web technologies (ever try to deploy Rails on Windows…with IIS? Yuck…)
The point is that some technologies are better suited towards certain problems than others, and a blanket organizational standardization on a single tech stack leads to a tremendous amount of wasted energy spent on driving square pegs into round holes. Ruby is not a great foundation for an enterprise-class messaging framework. Java is not a good choice for a lightweight CMS. And anything other than .NET is a bad choice for an app destined to be maintained by a bunch of MSDN types.
In fact, I’d argue that the cost of operation efficiencies lost by maintaining multiple tech stacks is exceeded by the cost of jamming technologies into inappropriate use cases. So, as messy as it sounds, any technical organization that is project or service based (as opposed to being exclusively product based) should maintain a strategic “quiver” of different technologies, so it can deploy the best choice when faced with a business problem. Otherwise a fragile monoculture is created, wasting a tremendous amount of developer effort, and adding artificial risk and expense to projects.