Simplicity and the Art of Boring Technologies

Here at zu, web developers love their ability to make choices; which technologies to use, which tools to develop with, which methodologies to adopt, deployment and server architecture choices… the list goes on. But the commonality of all these choices, and ultimately decisions, usually resonates around the idea of simplicity. We always strive for simplicity in our decisions - that doesn’t mean easy, and it usually leads to boring.

First, I want to describe what simplicity really means when we talk about it from a technical point of view. The easiest way to describe it would be to describe the opposite, which is complex. When tackling problems here at the office, we never sit down and attempt to come up with the complex solution. That would be analogous to building a space shuttle when you really only needed a bottle rocket. Complexity has too much overhead, and will inevitably start moving away from the real problem you’re trying to solve. So instead, we strive for simplicity. When we get that right, there is an elegance about the code and the end product.

A few other words crop up when thinking about simplicity, such as easy. When something is considered easy to you, you might also say it’s simple because you have a complete understanding of it. But if we think about this from a beginners perspective, something simple means a low barrier of entry to understanding the problem. Easy, on the other hand, is completely subjective, and relies a lot on experience. Someone with ten years of experience in a technology will likely say a lot of simple things are easy, but that’s not true for beginners, they might even say it’s hard. Even as seasoned developers we try to avoid hard problems, or making hard problems any harder then they have to be.

Embracing boring

Working in the web technology scene, we see a pile of new technologies, languages, frameworks, services, idioms, ideas…. everything under the sun! Everytime we visit web developer news sites like Hacker News or reddit, there is another framework, another technique, or another product that looks as if it would solve all our problems. Sometimes it’s hard to ignore what seems to be the latest and greatest, but there is always something to be said about the technology that we’ve being using consistently for the past few years. You could almost say it’s boring.

Dan McKinley wrote a great article on why boring technology matters. When we drink the kool-aid for one of the new technologies on the block, we have very limited understanding of its stability and maturity, and that can cripple a project from the get-go. Instead, we should embrace the known and boring technologies that have proven themselves over the years, the technologies that we are familiar with. When we go down that road, we know what to expect and how to handle those unlikely edge cases that always have a way of popping up during a deployment.

With all that said, I don’t mean to discourage you or become a luddite and say never use anything new. We need to evolve our technologies over time, and McKinley has a great take on how and when we should do this:

One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the “problem” is that someone really wants to use the technology. If that is the case, you should immediately abort.

My team was tasked with a new web application build last fall. We had the option of suggesting any new technologies for use, and that prospect was very exciting for us. But after considering what benefits we would gain from changing our application stack, we came to our senses and realized we could write a better application by sticking to our regular, and somewhat boring stack. Change for the sake of change is never a good mantra.

Slow and steady

I can say firsthand that zu has evolved its technology offerings over time. I have a very unique perspective on this as I worked at zu for five years, then took a five year break before returning. If you asked me during my first tenure, I probably would have said we were not evolving at all. But after five years, it’s very evident that zu has evolved and become masters of new technologies. It’s that slow, wise, and methodical pace that makes the difference.

If we can make websites and applications simple from a technology standpoint, we also gain maintainability and flexibility. The quicker a web developer can understand a given piece of code or functionality, the quicker they will feel comfortable and confident to bring positive change. This is why zu strives for simplicity.