A tech stack is more often inherited than it is chosen. On the rare occasion someone gets the chance to decide which tech the company gets to use for the next decade. I've seen this go well and I've seen this go belly up.

If you're in the right club, you know the answer; stick with boring.

The Postgres Paradox

When thinking about how long a technology will last I often use the current age of the software to determine how much longer it will be around. So if it's 2 years old, it might be around 2 more years. Postgres dates back 35 years, so it will probably be around for 35 more years.¹

We can view this in terms of experienced employees; we are more likely to find someone with 20 years of Postgres experience than we are to find someone with 20 years in a tech that's only existed for 2 years.

Taking the age of the tech into consideration allows us to earmark the hiring pool and the likelihood that fixes or workarounds exist for problems we might run into. Diving into newer tech increases the chance we are the first to come across certain problems.

The bleeding edge might appear shiny and new but we aren't here to ship blog posts we are here to ship features and delight customers.

These avoidable issues are hard to solve because of two reasons:

1. They're novel, we're the first to run into them.
2. The people that have faced this issue are expensive, because not many of them exist.

Make a Difference

Starting a business is a risk, picking fancy new tech is a risk. These risks add up. Where you decide to take the risk depends on where you are trying to drive innovation.

In 2015, London, two neobanks were founded; this is the tech they are built on and the tech's age at the time. Revolut is built on Postgres (25yo) and Java (19yo), the other is built on Cassandra (7yo) and Golang (6yo). The former has 50million customers, the later has 10million.

Risks are allowed to be taken, but we should limit the number of unknowns and not make things harder than they need to be. If we pick our entire stack on the principle of shiny and new we are going to be fighting our tech more often that we are solving customer use-cases.

Get excited about delighting users, not the fancy tech.

Don't be First, Be Fast

Early market leaders have much greater long-term success and enter an average of 13 years after pioneers.

Golder and Tellis (1993)

People make the assumption that if they're not using the latest technology they're not staying competitive, when they are instead just becoming a case-study for the industry.²

The study by Golder and Tellis tells us that first movers have a failure rate that is 6 times higher than fast followers.

If the tech stack mattered, you'd see it in advertising, but you don't, because the customer doesn't care. Your tech stack doesn't determine your product market fit³

Your investors might care (🤷).

If I had to choose between customers and investors I'd pick customers.⁴

The Right Tool for The Job

Ask a graduate what tool or language they would use for their next project and they'll give you a political answer: "I would pick the best tool for the job". Here's a list of programming languages. There are 50 that start with the letter A. Let me know when you've found the one that's best suited for the job.

Perhaps we should define what "best for the job", means. If we are in a team of 12 engineers that are maintaining 2 Postgres databases; introducing a MySQL database on the basis that it addresses a specific use-case better than postgres is not a good idea.

If we hire a DB expert in the future are we going to ensure they're versed in both Postgres and MySQL? It's niche but we could find them at a price.

We don't have to hire this DB expert, our team has built up experience with Postgres, now they'll need to familiarise themselves with the maintenance process of a new db. Just bumping your database version is now slightly tricker and you're monitoring news and bug fixes for both releases.

We could define "best for the job" as perhaps the one we are most familiar with, and this is often the best choice. If you can skip learning a new language or learning the framework step, you're going to get to market faster than others. Don't let learning the tech be the procrastination for learning the market.

In a startup we are testing our market assumptions, this is the largest risk to the company, we shouldn't slow down the speed we get to market. It's better to know we are wrong sooner rather than later.

Getting Experience

Engineers at startups might use the job as an opportunity to focus on CV driven develop instead of focusing on the needs of the business.

I've seen a graduate write every new project in a new programming language.

Anyone know Elixir? We're trying to fix a bug in production and the developer that wrote this is no longer at the company.

From a slack thread.

Starting every new project in a new language isn't a fast way to learn how to deliver. It's a fast-way to get 3 months of experience 5 times. Learn how to deal with a language's pain points and how to solve issues with a specific framework is what makes you valuable. If you're looking to stretch yourself, then use the same language and framework for larger projects.

If you've only got 3 months of experience in a language and framework you're probably not that hard to replace.

The new thing won’t be better, you just aren’t aware of all of the ways it will be terrible yet

Slide 84

Propaganda

Propaganda doesn't just occur in war or between competing states, corporate propaganda is a well established strategy available to large technical institutions.

Let's say you are working on an internal framework that holds up your billion dollar social media platform, you wish to hire more engineers to maintain and build the project. Training new hires on this framework is time consuming, wouldn't it be great if the engineers we hired were already familiar with the framework?

They can also hire developer advocates, these are the influencers of the software engineering world, corporate mercenaric missonaries that are very good at making the work they're doing exciting.

Ignore the hype, your job is to keep things simple.

Bleeding Edge

One reason you might wish to be in the bleeding edge of tech is to gain the expertise and then build around some of the fundamentals you've learnt. Perhaps your customers are others trying to enter the market, this is perhaps a safety-net for the risk you take, but the market can also flatten out and you're left holding a bag of air.