In a now-famous blog post, Software Engineer Dan McKinley wrote that startups should be wary of using bleeding-edge technology. He went so far as to argue startups have enough to worry about without dealing with the latest hot thing, so they should intentionally choose ”boring technology.“

As a general rule, McKinley argued that startups get “about three innovation tokens.” This is obviously an over-simplification since each organization will be able to adopt different technologies with different degrees of success. For example, it would probably be easy for a company to switch from GitHub to GitLab, whereas transitioning from services running on virtual machines to a serverless Kubernetes cluster is more likely to be difficult. The key point of McKinley’s innovation token metaphor is that the number of tokens is low. It could be four or five for some startups, but it’s not twenty. Startups need to be ruthless in conserving their tokens so they can spend them on the things that will be most impactful. All the small things can stay on boring technology.

Of course, Dan used the term ‘boring’ in his post as a compliment. Boring technologies are generally mature technologies, and their maturity brings a great number of advantages—even if it means the dev team doesn’t find them exciting. Some advantages of boring technologies include stability, reliability, supportability and scalability. Boring technologies have been battle-hardened over time and often come with a well-established community of power users. These people can make the adoption or migration to a boring technology painless.

Without the help of a community producing blog posts, sample code and video tutorials for exciting new technologies, startup staff will have to figure out a lot of things on their own. This can be very expensive for the startup that uses these technologies. New technology is also much more likely to go through breaking changes as the developers discover better ways to do things. This forces early adopters to do additional work to migrate to newer versions. One major example of this was the migration from AngularJS 1.x to the newer versions of Angular. Their first major release uncovered significant weaknesses and the team decided to rewrite the framework—even going so far as to change the name to distinguish between the old and the new versions. Teams using Angular today benefit greatly from these changes, but anyone who developed applications on AngularJS 1.x would have had to migrate or even rewrite their code in order to take advantage of the newer releases.

Over the last 5-10 years, DevOps technology has gone through a radical transformation; first the move away from on-premises machines to hosted virtual machines, and then to hosted containers. And this begs the question, are modern DevOps tools, such as Kubernetes, too new to fit into the boring technology category?

It is certainly true that some are, but it helps to think deeply about the particular tools and technologies. Over the last 20 years, you can see that the technology industry repeats the same trends. There's always something at the bleeding edge, but over time the successful technologies gain traction and attention and have to stabilize to allow them to scale. With success comes more process and requirements and familiarity. All of this moves the technology closer to the boring side of the scale.

As one example, back in the 70s and 80s, the first personal computers became available but they weren’t approachable to most people. Then, starting in the late 80s, we built simpler user interfaces, such as Windows and macOS, for these previously unapproachable machines. Inevitably, it got easier to work with these interfaces and the systems had to stabilize and scale to deal with all the new people who suddenly found that computers could be useful and fun for them.

These days, we’ve seen a couple of waves of cloud technologies and AWS, Azure, and GCP are becoming the comfortable new places to build applications. Now, we have the rise of Kubernetes, which hasn't reached the same level of simplicity—so it’s now the bleeding edge. As Kelsey Hightower has said on the if/else podcast, Kubernetes is a platform for building platforms.

It’s painfully clear that there are a lot of new tools in the DevOps domain, such as containers and infrastructure as code. These tools certainly simplify many tasks, but, while they're modern and they're powerful, they produce a level of complexity that tends to be difficult to understand when using them for a specific implementation. If companies adopt these tools without careful consideration, they could experience painful vendor lock-in down the line if they fail to catch on as industry standards. Companies may also find it difficult to hire the right people to handle their newly complex systems.

Hiring is a major component of the boring technology discussion that often gets missed in conversations about scalability, security, or cost. Even if adopting or migrating to an exciting technology will save an organization money in the short term, is it the right long term decision? If you adopt a technology that requires specialized skills, the answer might be ‘No.’ Startups don’t generally have extra people to spare, so if the one person on staff that can use their systems was to leave, who would take over? How easy would it be to replace them? It’s important to remember that choosing the right technology at the right time can actually make hiring easier.

All of these considerations put a burden on startups. If, instead, you are adopting these technologies in a mature organization, it would be helpful to carefully consider whether to use these modern DevOps tools. It might be that, for a while, you can get by on a simpler approach with a loose coupling of specific tools, and focus on building a really, really great developer experience. Looking forward, it's key to remember that tools that can abstract implementation details over time will gain in value as your environment scales. What each company should consider boring depends on where they are with their resources and which problems they're attempting to solve.