One technology to rule them all
I’ve heard or seen multiple versions of these statements during my time as a developer, and frankly you’re all idiots for buying into it:
- Devs shouldn’t have to learn multiple technologies / program in multiple languages
- Standardize all projects in one language and framework
- Rewrite non-conforming legacy code in one tech
I get it, we don’t want a situation where every single sub-system uses a different programming language / framework / etc. It’s certainly a balancing act we have to watch carefully.
But we need to STOP worrying about mixing technologies as if it’s going to destroy the universe as we know it.
Good devs should be adaptable
If your new devs need to learn a new language to do their job, this is a good thing. This exposes people to new ideas, new approaches, and in some cases totally new programming concepts.
If you hire a PHP developer who can’t figure out some Ruby code, you failed in the hiring process. The same goes for any two languages that are roughly in the same category. Yeah, you might not expect your PHP guy to pick up Haskell very easily, but if you have a valid need for using OOP and functional programming, you shouldn’t have to worry about demanding your developers to learn both.
Yes, you’ll pay more for versatile developers, but one-trick ponies are a very bad long-term investment. What languages were popular 10 years ago? 20? 30? If your devs can’t adapt every few years, hiring the Java-only guy will mean you’re looking for a replacement soon, rather than transitioning him to new things when your codebase needs to be replaced.
And that doesn’t even touch on third-party app support. At Musician’s Friend, we had all kinds of third-party apps, from Filemaker to custom solutions. In areas where we had in-house expertise, we could do some excellent stuff. On others, we just had to sit and deal with issues because we didn’t want our devs learning new things or something….
And in the library world, in just the first two years on my current job, I had a legitimate need to touch Java apps, Bash, Go, PHP, Drupal, WordPress, nodejs, Ruby, Rails, and some lesser-known technologies. We haven’t got the budget to hire a swarm of programmers, so we use a lot of third-party tools and open-source technologies, and as a developer I am expected to not flail like an idiot when something new heads my way.
Rewrite all the things in the next-generation fad of tomorrow!
I know somebody who actually practices (and preaches) this one. He’s insane. It’s a great idea, too – then everything is a Rails app, so all you need is a hammer… or something.
And when Rails is no longer the tool of the day? Then what? I get blank stares or “why would that happen?” Kids these days, I tell ya. It will happen because that happens with ALL programming. Hell, even modern C++ looks nothing like the stuff we learned in the 90s.
Full app rewrites take a great deal of time unless you’re supporting very few apps and the apps are all fairly small. If both of these conditions are true, congratulations — you’re working somewhere you’re probably not actually necessary, as the average college student can probably keep things running “well enough” once budget cuts hit.
At some point, you need to be able to weigh rewriting vs. maintaining. Yes, doing maintenance on 10,000 lines of horrible PHP can be cumbersome, but it’s not likely going to cost as much per iteration as a rewrite. Over the life of the product, it might save a ton, but the real world, especially where resources are constrained, doesn’t operate based on the ten-year ROI. It is sometimes better to spend $100000 a year in maintenance than to spend $250000 right now and cut costs down to $50000 a year. It’s not awesome, but sometimes you just don’t have the up-front capital / time to burn, and you have to accept that fact.
Stagnation
This one sounds a bit backward, but mixed technologies helps us AVOID the very stagnation the fans of rewriting are fighting. By letting your old PHP stay old PHP even though new apps are Rails, you’re making a statement that you don’t mind letting the old stuff stagnate some. But at the same time, you’re saying maybe Rails is worth looking into for future applications. And maybe later you do some backend services in C++14, nodejs, Go, etc.
Because you’re allowing mixed technologies, there’s room for adding new things. Because you aren’t constantly spending time keeping everything rewritten to the fad of the day, you have time to play with new technologies. Because you aren’t saying “JAVA FOREVER”, your developers are learning new ideas that can often help them even with the old code.
Hammer
Back to the hammer and the nail. Not everything is a nail, and we should be using the right tool for the job, shouldn’t we?
Yes, maybe we lean toward certain technologies for certain problems, but we should stop looking at every problem the same. If we need ten websites with a similar UI, a blog, and little else, sure, WordPress may be the right choice for all ten, and you’d be hard-pressed to convince even me that we should use C++ to build these sites. But when a low-risk project pops up, tinker with new technology. When a third-party service could solve a problem, but requires Python expertise, throw some time into learning Python.
In the long run, your developers will be better and you’ll have an easier time keeping up with new trends.