December 31, 2014
When I was in college, I worked with my dad for one summer in the maintenance department of an auto parts factory. One of the old-timers was a guy my dad called “Whizbang.” It was a moniker given with equal parts admiration and ribbing, because regardless of the challenge, Whizbang knew the solution. And sometimes… the failures were spectacular and hilarious.
Keeping things running – metal stamping machines, lathes, cutters, and the like – wasn’t a science, so much as an art. Some of the machines had manuals, but the maintenance crew rarely used them. They preferred experience won from working it out on-the-fly. It also turned out that the manuals were routinely wrong. It certainly wasn’t “by the book,” but the auto parts got made and the machines kept running because, underneath it all, the fundamentals were the same.
In the factory it was clear why we called it “Production.” The most important thing was to produce – to maintain up-time, to operate safely and legally, to get rid of as many bottle-necks and breakdowns as possible. It was important that your coworkers could support your work. It was not important that fixes were perfect, or even very pretty.
I bring that perspective to development projects and to the technologies I invest in. I love it when a great theory results in beautiful practice: unit testing, modular code, encapsulation, re-usability. But sometimes, when reality calls, you have to roll up your sleeves and get dirty.
So… when I read about new programming languages and technologies, I always look past the shine and ask: how will this new technology solve my problem? As I see it, before you create a solution, you need to understand the problem.
Earlier this week, a professor at MIT released a language and platform called Ur/Web. The promise? A single-language solution for deploying production-grade web applications and the answer to all the web’s problems: security, speed, and rapid application development. It sounds good, but it reminds me a bit of Whizbang back at the factory.
In August, Carnegie Mellon University also released a platform. Called Wyvern, it allows developers to write in any language. Put a dozen programmers at a table and ask them what the best programming language is. You won’t get a list; you’ll get a fist-fight. So with Wyvern, my production-oriented hackles went up as well. If your dev team can (and does) develop in their favorite languages, the support team needs to be proficient at all those languages. So at best, support will be expensive. At worst, you’ll end up with an un-maintainable nest of different languages.
Stay up to date with our email updates!