Why Over-Engineering Happens

The essay Choose Boring Technology covers some of this ground. From that essay:

"One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the “problem” is that someone really wants to use the technology. If that is the case, you should immediately abort."

https://mcfunley.com/choose-boring-technology

Another nice thing about the above essay is that it uses dark text on light background (as opposed to this blog post, which I had to print to PDF in order to read).

I have to say, though, that I really miss the days when I was the excited young programmer dying to use the new language, the new framework, the new paradigm or even just some design pattern. Lots of fun! Luckily, during those years, I was always in a team with a more level-headed and experienced developer who would bring me (and the other team members like me) a little closer to earth. And the level-headed developer was learning from us while he/she was moderating our technical ambitions.

> Default to the smallest thing that could possibly work

This is the key. I feel like the other 17 points all happen naturally if you heed this one.

"Release early, release often"

> ...when it started, the “backend” was just Google Forms feeding into a Google Sheet. No microservices, no Kubernetes...

This line of thinking is just as bad in the opposite direction. I'm not even sure either extreme strawmen ever really existed.

Great points about Over Engineering. No one ever seems to ever acknowledge how very successful Craiglist continues to be with a relatively simple stack because they really understand their customers.

One point I didn't see on there is lack of clarity of the objective of the JIRA Epics and Stories and verify that those underlie actual customer painpoints.

It seems like for every 10000 hyper scalable, cross region redundant clientside SPA MVPs that are blasted over Facebook or Google or PH Ads, there's one concierge MVP where the founders talk to you, find out pain points, validate them manually by hand and then grow organically.

In certain cases, it's even possible that no one in the engineering team had the confidence to say "Do we really need to build any of this at all to see if our startup has teeth?"

What would be interesting is to speak to the technical teams of companies like Quibi and ask them questions like:

- How are we testing whether this actually solves a real customer need?

- Who validated the need for Turnstyle Technology? How? When you launched, did you track how many were leaving the platform if it was turned off for them?

- Are there specific hurdles to serving short-form content that make a company built around it valuable?

- Are there ways we could help the leadership validate their market hypothesis by writing the least amount of code?

I imagine if any engineer was being interviewed to be hired at Quibi and asked them questions like these, their interview would be prematurely terminated.

It's widely accepted that both interviewing and working at a company especially at startup, requires suspension of disbelief, but I sometimes wonder if some of us should just say "No, we shouldn't do any of these JIRA tickets. There's a much simpler way of getting this done. Sal, Jane, Lin, come with me and let's talk to the customers and find out if this would even move the needle for them".

If everything around is smoke and scary shadows, then who knows whether that rustling in the shadows is a bear or a gopher? Over Engineer assuming the worst. Then we would be ready for a sudden million customers filing their taxes on a Friday evening in June.

The peace and fulfillment of knowing what the customer really is willing to pay for and building towards that is sublime. It's so addictive that there's absolutely no going back