Too Many Technologies and Specialization

The project on which I spend most of my time has, over time, developed a fairly heterogeneous architecture, from Java to .Net, from Oracle to SQL Server, from Reporting and Monitoring tools through shell scripts and web frameworks.

Technological Proliferation
As developers, it's important that we're able to make use of new technologies that we believe will improve productivity. An increasing technology mix can be desired sign in a project, even healthy, showing a kind of living vitality that stagnant projects lack. However, a ballooning technology mix can be a warning sign as well.

Getting that balance right is difficult, and probably warrants a post of its own. I'll come back to that another day. However, I've begun to notice a particular danger of a heterogeneous application mix recently: specialization.

Specialization
Some technologies are easily mixed by a given team. Even in the early stages of the project, it wasn't that hard to keep developers informed about how to use Tapestry, Spring and Hibernate in concert. Java developers are used to using a mix of libraries and frameworks to get their job done, and this project is no different. Although we had a single specialist in the form of a database developer, there was a fair amount of overlap, as all of the Java developers were in and out of the database on a regular basis, making changes, learning the structure of the schema; the specialization was really one of 'ownership', not of knowledge.

As the project grew, a number of external forces caused the technology mix to grow. We added an analytical datastore, reporting technology, an ETL tool, monitoring and scheduling. We mixed in some .NET technology to take advantage of some components that we couldn't easily incorporate otherwise, and web services to bridge the two.

As this happened, the team started to specialize. Reporting developers were added who knew the reporting technology and became familiar with the analytical datastore. The database development team was expanded to handle the analytical datastore and the ETL tooling. Some operational people became experts in the monitoring and scheduling. Some of the developers worked on the .NET technologies while others didn't.

The Impact of Specialization
When your team members specialize, they gain some efficiencies. A developer can focus on a particular technology or set of technologies. He or she can become expert by working in that technology alone. There are also some costs to pay.

Specialization reduces your 'bus number': the number of team members who can be 'hit by a bus' before your project is SOL. It also reduces your resourcing flexibility. Don't have any pressing reports? Too bad your reporting developers can't add a core feature. Having trouble with the ETL? Too bad your Java developers don't know how to install SSIS, let alone use it.

Each project has to make this tradeoff for itself; neither is wrong, it's just a decision. But it may not be a decision you have to make.

Do We Have to Specialize?
Here's the key: specialization is starts to be appealing if, and only if, you start to use a large number of disconnected technologies. So when you're adding a technology to your project, ask yourself if you're walking down the wrong path.

For instance, if you're considering writing scripts to interact with the database because you can't afford to build a user interface, ask yourself: Is there another way? Can we fold this into the interface using code generation, or a framework that simplifies CRUD? Is there a way to build this in a technology you're already using?

Does your team specialize? Do you use a wide mix of technologies, or have you found a way to keep it down to a small set?