December 31, 2014

Blog | Development | Whizbang

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/WebThe 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.

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: different languages can be a good thing for a project, if those languages are well-enough understood to be used effectively.

About three years ago, in a room full of developers, I asked, “Why on earth would you run JavaScript on a server? That just seems like a ticket to misery.”  I was talking about Node.js.  My mind has been changed because Node is a great tool and it stands up well in production.  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 mouthful, but it solved a lot of problems developers were facing at that time.  In short, he understood the problem, and he solved it in a simple way.  He gave us the right tool and he wasn’t trying to solve all the problems of the web.  He wasn’t being a Whizbang.

Dan Clouse

Senior Developer
  • Concept
  • Theory

Recent Work

Check out what else we've been working on