In Defense of Boring Old Technology
I’ve noticed a few forces at work in my software development life. While I have no interest in being exhaustive (or exhausting), I have some thoughts on a few of the common ones: The Variable Definition of Correctness, The False Promise of Greatness, What is Fashionable Right Now, and Pragmatism.
The Variable Definition of Correctness
If you’ve done this software thing for a while, you’ve invariably run into the Variable Definition of Correctness. You may have been learning a new library, language, or framework and, heaven forfend, tried to apply your previous experience. Ah, but you’ve made a mistake, for this new library/language/framework is a unique snowflake and you must unlearn all the old/wrong ways in order to embrace the new/right ways.
While I would agree that the overall trend in our field is towards progress, I would argue that most changes are incremental. Few things are truly revolutionary and even at that, our overall modes for programming are still limited to a few channels: imperative, functional, logical, etc.
The positive way of applying this is to consider that skills advancement down a particular mode of programming should be considered transferrable knowledge to new technology within the same mode. Have you learned a bunch of lessons in Functional Programming? I would hope those are transferrable to the next hot FP language comes out. If the community tells you you’re wrong, it’s possible that there is a community-wide lesson waiting to be learned.
The False Promise of Greatness
But Zack, you might be saying, you haven’t seen the benchmarks for Exciting New Technology (ENT). If you act today and switch now, you’ll be able to ship ten times what you could on Boring Old Technology (BOT).
Again, there are kernels of truth here which don’t represent the whole picture and the distortion is in the magnitude. I would argue that most ENTs are optimized to deliver a specific on-boarding experience, by which I mean, demo-able at a conference or in a webcast.
An example of this, using what many consider to be a BOT, would be the “Build a Blog in 15 Minutes” video by DHH when Rails first launched.
Let me tell you, I still remember the day I watched that video. I was in the ninth circle of Enterprise Java hell and the idea of being able to be that productive was heaven sent. Was I making an apples to apples comparison? Of course not! My day job was on a highly performant pricing engine, Ruby then and now would never have worked. And let’s be honest, once you got past those first fifteen minutes of running generators, there was still a lot of work to be done.
But something interesting happened: people who had cut their teeth and learned their lessons on Smalltalk started writing books for the Rails community. Lessons were shared which redirected some of the early Variable Definitions of Correctness to practices and approaches born out by experience over decades.
Did Rails Promise Greatness? Yes, but it did in a way that is mundane and customary. Every ENT does the hot demo thing. I would argue, however, that Rails is pretty awesome not because of the intrinsic benefits of Ruby or the Rails framework itself, but because of the countless heroes that make it great.
Unfortunately, I think many people adopted Rails because they heard it was hot, which takes me to my next point.
What is Fashionable Right Now
Although we are all quite logical people in the software business, we happen to suffer from the same thing everyone else does: we’re human. Humans are, and always have been, herd animals. While some would carry that to its derogatory end, I would rather point out that it’s a strong survival trait and leave it at that.
Those venturing out on their own are, just that, on their own. Their survival rating drops, they have fewer resources to deal with threats, and only a few are strong enough to blaze trails. However, when we gather together we can tackle something big! I mean seriously, we’ve been to the moon and back, we’re pretty handy creatures when we work together.
At this point you might be asking yourself, “why did he describe it as fashion then?” Excellent question, you must be very smart.
I did so because I think something about our current time has caused us to lose the focus required to truly evaluate trends. As such, if we see a well designed site that has a powerful demo around a felt need we have, we think, “I’ll be happier and more productive if I join that herd.”
The truth is more nuanced than that. Since software is largely reproducible, you will be more productive in the niche you were enticed by (this is a reiteration of the point I made above), but what about after the first fifteen minutes?
This is where we need to get beyond the hype and make sure we are aligning choices with values. For many, the primary value is measurable results, so rather than belabor the point here, let me move on to Pragmatism.
Ironically, after using Rails as the “negative” example above, I’m going to use it as the “positive” example for my final point.
No matter what else you might be able to say about Rails over the years, you cannot deny that it has delivered on its promise to be a very effective framework. Originally framed and continually developed by people who ship features every day to a real user-base from which they need to make money by delivering value (as opposed to the many technologies that are outcroppings of intellectual exercise or entertainment), Rails has proven itself effective.
I think this is where we can sometimes lose sight of our objective. It would seem that our primary job (as far as our customers are concerned) is to provide the best service possible. This is an eminently measurable thing. We can ship more features, eliminate bugs, improve performance, etc. But if we’re not careful, things like The Variable Definition of Correctness, The False Promise of Greatness, and What is Fashionable Right Now constrain our efficiency and reduce what we can deliver to our customers.
The Role of Scarcity
But here’s the thing, we don’t all have the same goals!
When a company is fighting to survive, it has to prioritize delivering monetary value as efficiently as possible, or it will cease to exist. This is the territory of BOTs. Choosing ENTs here is basically gambling with your investor’s money, which is only ok if they are ok with it.
Once a company has developed a long enough runway, maybe it can make some bets on ENTs that may or may not work out, as it’s an investment for the future and possible incremental advantage.
Finally, when a company is so beyond having to worry about financial matters that it’s in the top level of Maslow’s pyramid, their decision making process is essentially unconstrained.
Clearly, if a developer in a resource scarce environment adopts the approach of a post-scarcity company, it might make for some long nights.
I think understanding these forces and our constraints will help us make decisions that are aligned with our values. If you care about efficiency, measure it. Judge new frameworks by it. But also recognize that too much of technology polemics is driven by the false dichotomy that you have to choose the BOT or the ENT, whereas the trick is knowing how and when to use them both.
Thanks for reading!