One summer during college I worked with my dad in the maintenance department of an auto parts factory. One of the old-timers in the department was a guy my dad called “Whizbang.” It was a moniker that was equal parts admiration and ribbing, because no matter what the challenge, Whizbang knew the answer and strode in to fix the problem. 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 pre-dated me, but still had the manuals tucked into cabinets on the side. The guys from the maintenance department rarely used the manuals though. They preferred experience and the habits won from working it out on the fly. It also turned out that the manuals were routinely wrong. Users didn’t use the machines as the manual implied, the controls shown weren’t the same as those on the actual machine, wiring diagrams were outmoded, previous repairs had change the configuration… It certainly wasn’t “by the book,” but in the auto parts got made and the team of maintenance workers all knew how to keep things running because underneath it all, the fundamentals of every machine 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.
Now I’m a coder and I bring that perspective to my projects and to the technologies I invest in. I don’t thump my chest about the ugly code I write; just the opposite. I love it when a great theory results in beautiful practice: unit testing, modular code, encapsulation, re-usability. But sometimes when reality imposes itself you have to roll up your sleeves and get dirty. Because user experience matters. Because up-time matters. Because safety (of data and users) matters. Because bottlenecks and breakdowns are not acceptable. Because it’s production code.
With that preamble, when I view new languages and new technologies, I always look past the shine and promise of having all my problems solved and ask the question; how will this new technology stand up in production? I might sound like a curmudgeon, but I think I’m just the opposite: I eagerly adopt tools that solve my problems in better ways.
But pardon me while my production-focused skepticism shows. Ur/Web promises it knows the answer to all the web’s problems: security, speed, rapid application development. But it reminds me a bit of Whizbang back at the factory. One guy might know all the answers, but that doesn’t mean he’s right all the time.
Java was supposed to be the single-language stack and flopped spectacularly in that regard. Do you remember Java Applets? For one hot minute Java was the future, and then it wasn’t. The reasons were many, but in short, it couldn’t stand up to the expectations of production use. Things were too slow, to fragile, too bulky, too expensive to write and maintain. Java is a fine language, but the single-language-stack dream was never achieved because Java isn’t a good enough language for everything all at once. It’s Whizbang.
I recently looked at a web development language and platform (released from Carnegie Mellon University) called Wyvern that allows a developer to write in any language. Put a dozen programmers at a table and ask them what is the best programming language: you won’t get a list of 12 different languages, you’ll get a fist-fight and life-long enemies. So with Wyvern, my production-oriented hackles go up as well. If your team of developers 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.