Here’s another collection of ideas on doing less to do more. This comes as much from personal experience as from things I read. A particular piece of inspiration was this 2015 article, but the topic had been around longer than that.

You may find this useful if you are building something (or asked to do so). I’ve mostly done things with computers, so that’s the main flavour.

1. Don’t suffer imaginary problems

This is the tech version of Seneca’s ancient adage. I’ve seen many people trying to solve every possibility and edge case they can imagine. The really good ones put a lot of effort into imagining a lot of these things.

In technology projects, imaginary problems come mainly in two main flavours:

• We need more scale
• We need more features

You need less of each than you think. It’s sad to see a team wrestle with a Kubernetes cluster (we may need it in the future; better do it now) instead of doing something useful. Or build feature #47, instead of just launching the damn thing, so they can maybe see if customers need it.

The fewer imaginary problems you solve, the simpler your product will remain. Simpler things are cheaper to build and run. You can spend all that time and money on doing the things you actually need.

Observation: the bigger the company, the more imaginary troubles you'll have.

2. Use boring technology

What’s boring? Boring does not mean bad. It rather means something that worked well for a long time. Postgres, PHP (don’t kill me), Python, DNS, CRON. Hell, even Java, if you can bear the boilerplate. These things are not popular the same way shiny new things are.

(Of course, there’s tech that’s both boring AND bad; I’ve heard it’s called “enterprise software”.)

Boring technology is well understood, by a lot of people. They can build things with it, operate it and fix it when it goes wrong.

Boring things also have a very useful habit: they rarely break in new and interesting ways. (They did that when they were not boring yet).

Ah, and the best one: your customers don’t care. Remember, you are - most likely - not part of an art project, so you build something that people pay money for. What kind of database you use will usually not make or break the product.

What about using the best tool for the job?

Unpopular opinion: when you need to get something done, that’s not the right time to try out new stuff.

But shouldn’t we learn new things? You should absolutely do all that, but not as a default behaviour and again, driven by “but I heard”… Also, it’s best if you don’t start using the new exciting tool in production.

Observation: the more engineers you have in the room, the more you may be asked to get more stuff.

3. Use as little technology as possible

First, technology may not even be the solution - or the best one - for your problem. But let’s assume it is.

Every additional piece of tech you add also adds cost - in complexity, in operations (backing it up, securing it, doing upgrades, whatever). Or, to put it another way, the more you can use something you already have, the better.

But the cloud makes adding new tools cheap, no? Say everyone who hasn’t paid an AWS bill yet for anything at a reasonable scale. (I like AWS, for certain things.)

Try solving the problem with your existing tools before getting new ones. Tools that have been around for a while are remarkably universal: besides storing relational data, Postgres can also be a message queue and a NoSQL database. Is it the best tool for those use cases? Surely not. Do you need that in the beginning (and if you are not Google)? Surely not, as well.

One caveat. No, make it two

Boring technology can, over time, become “legacy technology”. After a while, most things:

• are not very well-known any more (just look at any banking system)
• stop evolving and become obsolete in practice.

Just like Roman aqueducts, these things will (and do) still work just fine for what they were built for. However, building anything on top of or with them is rather difficult. Also, good luck finding anyone who still remembers how they were built and how to fix them.

This will take a long time, though and may still be a better outcome than using a half-baked, was-the-shiny-thing-6-months-ago tech that suddenly no one wants to touch or remembers.

Finally, of course, there are exceptions.

When the thing you work on is a main differentiator, you may need that fancy new piece of tech. When you are Google, 1-2% of performance gain may save you millions.