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.

Recently a number of articles have come across my desk, touting the newest salvation for the headaches of developing websites.  The latest is a language and platform called Ur/Web.  released by a professor at MIT, it promises a single-language solution for deploying production-grade web applications.  I’ve worked on good-sized teams with specialists in HTML and CSS, JavaScript, C#, C++, PHP, SQL, and other languages, so I understand the headache and overhead of solving a single problem- “the website”- with many languages and technologies.  The technology stack looks like alphabet soup.

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.

The truth is, different tools are good at different things.  SQL is great for set theory and data manipulation.  C# is really solid for writing the behind-the-scenes code to make desktop and web software work.  JavaScript (when done well) is excellent at handling user interaction.  This list can go on and on, but the point is using different languages can be a good thing for a project, if those languages are well-enough understood to be used effectively.

As I see it, the problem is understanding the problem.  I wrote last week how JavaScript is taking the web by storm, in part because the biggest problems on the web today are on the front end.  We don’t need more languages or tools to solve the well-solved problems.  We need them for the unsolved problems.  And to solve those problems, we need to define them and understand them.  In this case, places like MIT and Carnegie Mellon at doing a great service by researching and working to develop new tools and languages.

I’ve been wrong before.  About three years ago, I said out-loud to a room full of developers, “Why on earth would you run JavaScript on a server? That just seems like a ticket to misery.”  I was of course talking about Node.js.  My mind has been changed, for a number of reasons, not the least of which is that Node stands up in production pretty well.  But really it’s for a different reason. Ryan Dahl created Node to solve one problem, and one problem only: he wanted non-blocking asynchronous network operations.  That’s a technical mouthful, but it turns out that a lot of the problems other web developers were facing were solved when he came up with Node.  In short, he understood his problem, and he tried to solve it in a simple way.  He wasn’t trying to solve all the problems of the web.  He wasn’t being a Whizbang.


Submit a Comment

Your email address will not be published. Required fields are marked *