For this project, I needed a database and, as you know my love for anything SQL-related, I narrowed my options down to either using plain PHP or Laravel. Eventually, I opted for Laravel because I like its object-relational mapper (ORM), Eloquent. While at it, I reached out to a friend developer to ask for some advice and expressed my concerns about using Laravel and CRUD operations to simply scrape data off an API and populate a MySQL database. It seemed excessive—admittedly, it was.

His response was intriguing; he recommended GraphQL for such front-end tasks. Eager to try something new, the junior developer in me responded instantly, "Great, I will use that." To my surprise, I hadn’t noticed the three floating dots in the chat indicating he was still typing. His follow-up message arrived just after my enthusiastic reply: “But I would avoid using it for now, just stick to what you know.” And then he shared a link to McKinley’s March 2015 article, “Choose Boring Technology”.

After reading the article, I was convinced to continue with Laravel. Here's why.

McKinley introduces the concept of Innovation Tokens. He proposes that companies hypothetically have a limited number of these tokens to spend on new technologies. However, companies often overestimate their capacity and end up using more innovation tokens than they have available, which is clearly detrimental. The underlying message is to conserve resources, given the finite number of tokens available to spend.

To illustrate this idea further, consider the case of Immanuel Kant. Known for his structured routine, Kant's daily schedule was so predictable that neighbors would set their clocks by his walking times. He believed that such regimentation freed his mind from mundane decisions, enabling him to focus entirely on his philosophical pursuits.

In essence, Kant effectively allocated his "innovation tokens" to philosophy rather than trivial matters. Thus, it's reasonable to suggest that Kant would have endorsed the concept of innovation tokens.

Kant's purported walking route, Source:

Given the finite nature of these tokens, the logical question arises: how should they be spent? Yes, you got it: boring technology.

But what exactly does McKinley mean by "boring"?

“Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad [2]. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.” - McKinley*, Choose Boring Technology* (2015)

According to McKinley, boring technologies are not inherently bad. Instead, they often align with being "constrained," indicating that their capabilities and, more importantly, their failure modes are well understood. Drawing upon the "Rumsfeld matrix," we can view it as follows: there are 'known unknowns' and 'unknown unknowns' (the latter being the problematic category).

Known unknowns are variables or outcomes that we are aware exist, but whose impact or nature we cannot predict accurately. In the context of using "boring" technology, a known unknown could refer to predictable types of failures that are understood and can be planned for. For example, a database like MySQL might fail under certain well-documented conditions (such as overload during high traffic), and although the exact circumstances of the next occurrence are unknown, the potential for such an event is recognized.

Unknown unknowns refer to unforeseen challenges that arise, which were not anticipated or previously considered - not to be conflated with Black Swans.

The risk of unknown unknowns is typically higher with newer technologies where the breadth of potential problems has not yet been fully explored or documented. Because these technologies have not been tested across a broad range of real-world scenarios, their failure modes are not well understood, making their risks harder to manage.

This risk assessment and prevalence of "boring" technologies in order to mitigate risk gets boosted by another important concept, often overlooked in tech. Namely that technologies don't happen in isolation.

In modern organizational environments, technology choices impact not just individual projects but also cross-functional teams and the broader business ecosystem. The integration of a new technology can affect workflows, introduce new types of risks, and require new knowledge or skills. Given our current context of highly interconnected systems (including your company and your code), I must approach this from Taleb’s perspective on antifragility.

A quick refresher:

• Fragile: A system or entity that is easily damaged or deteriorates when subjected to stress, shocks, or unexpected changes.

• Robust: A system or entity that can withstand or resist stress, shocks, or unexpected changes without suffering damage.

• Antifragile: A system or entity that not only resists but also benefits and improves from stress, shocks, or unexpected changes.

Resisting the allure of solely pursuing Antifragility, a company should instead strive for a foundation of robustness, sprinkled with elements of antifragility strategically incorporated. While I understand the ambition of companies aiming to solve world hunger or revolutionize the global economic system, let's approach it methodically, one step at a time.

'Boring' technologies, which are well-understood and have predictable behavior and failure modes, contribute to robustness. Because they are tried and tested, these technologies are less likely to cause unexpected disruptions and can handle stresses more predictably, thereby stabilizing the system.

By using technologies with known behaviors and interactions, organizations can reduce the incidence of negative surprises (reduce fragility) and focus on growth and innovation in other areas, potentially turning challenges into opportunities - read: you can taste antifragility too.

The costs of new technologies can go beyond what was initially expected and calculated. Adding new software to an existing stack can bring unexpected costs. These include training for team members, potential compatibility issues with existing systems (like databases), and unforeseen failures that have not yet been documented or understood - unknown unknowns. Such risks highlight the fragility introduced by new, untested technologies in a connected system. If these risks materialize, they can cascade through the network, affecting various parts of the organization.

Of course, there's a downside to this conservative approach. What if the new technology is genuinely superior, and you're simply not aware of it yet?

“The problem with “best tool for the job” thinking is that it takes a myopic view of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible.” - Dan McKinley, Choose Boring Technology (2015)

By prioritizing 'boring' technologies and being cautious with the introduction of new technologies, companies can manage their exposure to systemic risks. This doesn't mean shunning innovation but rather integrating new technologies thoughtfully and with full awareness of their potential impacts on the entire system.

Before integrating a new technology, pause and assess whether you can address your existing challenge without introducing anything new. If the answer is 'yes,' refrain from incorporating a new tech into the stack. However, if the answer leans towards "no"—it rarely is just "no"—then proceed with the implementation. And this concludes the article.

...

Yes, I know what you are thinking. As they say in Italy, "I know my chickens." Being a developer myself, I understand that the answer is rarely a straightforward yes or no, but often falls into the realm of "Yeah, I guess I could do it, but it would be too hard and clunky." In such cases, McKinley, in 2015, suggested being more creative. In 2024, however, you even have ChatGPT to assist you with that creativity, if needed. No excuses, unfortunately.

In conclusion, the insights shared in this article stem from my desire to embark on a personal project using familiar, "boring" technology. When asked what would make a developer happy on the job, many might respond with a desire to work with certain programming languages or tools. This inclination often reflects a tendency among developers to chase the latest trends and focus on short-term gratification, sometimes neglecting broader considerations beyond technical aspects—something most developers are really good at doing.

However, in my brief experience, true fulfillment for a developer lies in the act of shipping—delivering tangible results. Therefore, it's essential not to squander valuable time constantly learning new stacks, languages, or endlessly tweaking minor details like changing Visual Studio Code themes multiple times a day (a habit all too familiar, unfortunately).

This notion brings to mind a tale attributed to a renowned screenwriter—perhaps William Goldman, though the exact source eludes me. In a lecture to aspiring writers, he bluntly asked, "Who among you wants to be a screenwriter?", and when the majority of students raised their hands, he abruptly replied, “So what are you doing here? Go home and write!” His message was clear: take action.

So, what am I doing here? Simply attempting to delay encountering Laravel for as long as possible, I suppose. But no need to fret, I'm off home now to write—or should I say, to code.

If you enjoyed this article, please consider giving me a follow. Your feedback is greatly appreciated. And remember, I'll be writing more whenever I need a break from code and API calls.