As human beings, we’ve evolved to treat boredom as the enemy. Every day we pursue more mental stimulation, seeking out new ways to occupy our minds lest we succumb to the horrors of having to sit quietly in our own thoughts. We restlessly thumb through content on our permanently connected devices, seeking the dopamine hit that can only be sustained through active neophilia.
This isn’t a new phenomenon, of course. Back in his 1930 book “The Conquest of Happiness”, Bertrand Russell wrote in that “We have come to know, or rather to believe, that boredom is not part of the natural lot of man, but can be avoided by a sufficiently vigorous pursuit of excitement”.
From my vantage point in the DevOps world, I’ve seen this attitude towards avoiding boredom spill over from our off hours into our working lives. In some cases this is a positive influence: for example, boredom at the idea of maintaining a large estate of servers by hand is one of the reasons we developed automation tools to do this work for us. However, trying to keep things exciting can have a negative impact too.
Many of us ended up in our technology careers after starting out as hobbyists, tinkering with systems for their own sake. Technology is interesting precisely because it is continuously evolving, and willingness to learn new things is often a trait we hire for. It’s perhaps because of this that we have a tendency to succumb to fashionable whims when selecting components for the systems we build. These choices, made in the quest for excitement, can be dangerous unless they’re also evaluated in the correct business context.
Software doesn’t just spring into life, fully-formed and bug-free. It evolves over time as users discover faults and performance issues, or find that they need new features. I’m going to take the NoSQL database MongoDB as an example. It was released in 2009, the year my consultancy was established, and in this time a number of clients have made use of it, some of whom almost certainly chose it because it seemed new and exciting.
It took two years from that first release before MongoDB added data journalling, a feature necessary for write durability in the event of node failure. Shortly after, and with a major version number increase, authentication support was added (though not enabled by default), and it took a further two years before it was possible to configure access control by role, or to connect using transport layer security. Audit logging of database activity against authenticated users came another year later, in April 2014, but only in the non-free version of the software.
It wasn’t until MongoDB 3.4 was released in November last year that the software was verified as safe to use in clustered environments, following work to solve data integrity issues with lost updates, dirty reads and stale reads under certain cluster failure scenarios.
Different businesses have different requirements of their technology in terms of availability, data integrity, performance, cost, security and more. It’s important that these requirements are considered when selecting tools — by stakeholders with both development and operations in mind. Fashion will certainly play a part in this process, but it shouldn’t be the only consideration or even the main one. If you were a pharmaceuticals business making database choices in 2012 then MongoDB, although fashionable, wouldn’t have been a good choice because of the lack of available security controls. Today, assuming you’re willing to pay for a version with enterprise features, it could be worth considering.
I hope it’s obvious that I’m not trying to hate on MongoDB here, the point I’m trying to make is that software becomes more trustworthy, stable and predictable — boring, even — over time. Over the same timeline, it will become less and less fashionable. If your teams are making choices based on fashion, they will very often be the wrong choices.
Choosing “boring” software is powerful. Troubleshooting is easier and less time consuming when it involves a search of Stack Overflow instead of installing a few hundred meg of debugging symbols than busting out gdb — and how many Javascript developers would even know how to do that? The time you’ll save not being the first person to discover a particularly troublesome edge case can be spent instead on enhancing your own product, which is where your real business value lives. Customers interacting with your apps rarely care what they’ve been built with — they just want to make their purchase and move on.
There may well come a time when some bleeding edge tool or library will genuinely give you an edge over the competition that nothing else provides. In that scenario it absolutely makes sense to use that technology, but take the time to consider the risks, mitigate against those that can be controlled, and ensure you understand the costs involved.
We’ve been an AWS SaaS Services Competency Partner since 2020. If you’re building SaaS on AWS, why not book a free health check to find out what the SaaS SI Partner of the Year can do for you?
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
