Juan Saavedra

One great thing about the present-day abundance of software tools is that you get a lot of options when faced with a problem. These tailored solutions often provide a (almost) fully functional open-source version that you can set up in mere minutes and incorporate into your project.

Going through what seems like a magical tutorial, you find some clear code examples in the language of your choice, and some SDK or library to integrate it as straightforward as possible.

You might expect that I will strongly guide you against this kind of solution by this time. Not really. Providing some wildcard answer for all tradeoffs is impossible, and many of those tools can bring immense value.

But I think that when doing tradeoff analysis in these scenarios, one thing gets often overlooked or seriously downplayed: increased complexity.

The problem with complexity

Complexity is usually correlated above linearly (i.e. exponentially) with bad things such as «downtime», «hard to change», and «unpredictable» in a long and not flattery list. In simpler terms:

complexity very, very bad

The Grug Brained Developer

Some argue that complexity is not necessarily bad and that there are different types of complexity. I agree with that, but it is a sophisticated analysis that does not apply to most scenarios. In fact, you should strive for radical simplicity.

I believe part of the problem with keeping complexity in check is that it is intuitive to estimate overall complexity as the addition of individual components. Like the example in the intro, you might be induced to think that the additional complexity of such a tool would be low. However, you should actually multiply all the different relationships as well – which usually brings a lot more complexity than expected.

Think in moving parts

When designing physical stuff, whoever is in charge will probably want to reduce the number of moving parts as much as possible. It makes it easier and cheaper to manufacture, it makes it more reliable, and easier to support at scale. You might have seen how important this can be if you read anything about electric cars, whose powertrains have an order of magnitude fewer moving parts – quite an advantage!

Over the years I’ve found the shortcut of thinking in «moving parts» as a practical approach to keeping complexity at bay. In software, I’d define it as a moving part as a standalone component or service that is necessary for the correct operation of a product – which should be all there is in a project.

Some moving parts have different weights (Is the service being provided by a third party or are you running it? Are you using a long and established product or one from a newly launched startup?) but they all will eat from your «complexity budget».

A practical recommendation

There’s now an ever-growing trend of relying on Postgres for many things, drastically reducing the need for additional components in a given system.

That, based on my personal experience, is something I can endorse broadly. I’ve successfully used full-text search, JSONB, and Timescale as a time-series db – without the need for additional moving parts to solve problems as it was the case previously.

While you might need some complexity down the road, having the elephant trump complexity for the moment is a safe bet that usually pays.