I was thinking about the different kinds of technical diversity as I was driving to work this morning. On the one hand, there is planned technical diversity, which is when we intentionally use multiple technologies that exist in roughly the same sphere. Having some scripts written in Perl and others in Python would be an example. Either could, theoretically, supplant the other, but it is probable that they are suited to different tasks. Maybe Perl is a better fit for some textual parsing than Python. Sure, it could be done in either, but maybe Perl makes the work lighter (for someone).
Then there is the mirror opposite of planned technical diversity, which would be incidental technical diversity. I find that this most especially happens due to good old lava flow. We wrote in classic ASP before it was classic, then did new projects in ASP.NET webforms and finally moved over to ASP.NET MVC, but didn’t refactor or replatform the older code. It just lived on happily. The result being that we have a form of technical diversity that no one ever quite decided to take on.
The lava flow scenario is seldom good as most of the layers are in the process of becoming obsolete. But there is, I think, some value in planned technical diversity. There is a balance involved, as I’ve mentioned before. As before, I don’t know that there is a lot to mention with respect to risk. It has been amply said and generally applies to the most degenerate of situations.
One advantage is that, by maintaining an advance guard, we never find ourselves suddenly desperately behind the times. After all, our code bases don’t magically go out of date one day. They rust one day at a time. Expecting to stay current without continuous change is not reasonable.
Talent recruitment is another big thing. The best developers want to work with the best technology and want to to try the newest at the very least. It may not be possible to make the core product more glamorous, but it is possible to ensure that there is ample room for developer skill to work.
The last advantage I can think of is that technical diversity is itself a form of risk management. That is probably an ironic statement, given that risk avoidance is often one of the key arguments for restricting the toolchain available to an organization. What is interesting is that obsoleted tooling must be either maintained internally or replaced, regardless of whether or not it is open source. The difficult thing is that we can never really be sure which selections will turn out to be good ones, in which cases or for how long. Moreover, we can never be certain where we will run into unexpected security holes. By having investments in multiple technical stacks, we are protected against sudden dramatic issues with any single one. We are less likely to find that we have to apply emergency patches to everything or suddenly replatform the entire system.