I was talking to some friends about development decisions and we ended up deep down the rabbit hole of simplicity. I’ve commented on this in my scale rant, but realized during the conversation that a few ideas I think are obvious aren’t obvious — or agreed on — to everyone. So…

Driving toward your goals

When you’re delivering products, everyone should be thinking about measuring progress as rate of positive change delivered to your customer. It’s a challenging but excellent metric that people can feel and impact. It’s a great tool.

I also discussed a way to organize product development into three distinct phases: thinking, building, and learning. Simplicity, when properly applied, helps all of these.

Simplicity of development environment

Everyone — ok, everyone mostly — agrees that standardizing development environment and tooling is important. It means you can document it, onboard people, maintain it, etc. much more easily than an infinity of bespoke tools. Where I like to take it a step further is to use simplicity as a lever to apply back pressure to the environment. Why use AWS and Vercel if Vercel alone would do right now? Do you really need a bespoke graph database when PostgreSQL will do?

Look Mr. But Actually, I’m not saying you need to have an Emacs vs vi cage match. Unless, of course, some particular editor plug-in or component is central to your work flow in which case by all means make a decision here and stick to it! Similarly, if you’re building a product for multiple platforms, it may be very important to split teams across Mac and Windows, Android and iPhone, etc. But it’s not enough to have one person add complexity to everything because they prefer ctrl to cmd or “just don’t like Google Sheets.”

The more senior and smaller your company/team is, the harder this will be to manage. Smart, experienced people always bring their preferred tools with them and have great arguments for why it will be a net win. Listen and get feedback from your entire team, experiment, but don’t fall into the trap of monotonically increasing complexity.

A developer specific one: Language boundaries

Growing up as a programmer in the ’80s — plus starting in arcade — taught me to worship at the altar of Kernighan and Ritchie despite some professional dalliances with Ada and Pascal. Part of the joy of that era was that it didn’t really matter where in the stack you were operating — C was your hammer and the world was full of nails. Meta felt like this as well, except the hammer was PHP (at least until everything changed). Looking at full-stack mobile development today, most companies have gotten themselves to a very different place. Kotlin and Swift for native code, TypeScript for browsers, Python for AI interfaces, and then a smattering of languages from C to Go to Rust for the server code.

Why does this matter? Can’t engineers either be fluent in all the languages or hand work off to each other?

In my experience? No.

Instead what happens is engineers try to solve problems where they are most comfortable. Requirements and ideas get lost or mangled at team boundaries. Or even worse, developers just decide not to try their idea. Unexpectedly, you create situations with teams or individuals becoming single points of failure. Projects grind to a halt because the key person is OOO.

You change this by picking a language and using it for as much of your development as possible. For web and mobile development — plus AI integration — TypeScript is pretty amazing for this. Thanks to wasm, it’s not even the only option.

Simplicity of product, design, and experience

Simpler user experiences — like simpler designs — are often way harder to imagine, discover, and create. Simpler means removing past ideas rather than letting things grow by accretion. Exploring simpler means having genuine rigor about whether changes are good — from the end-user perspective — or not. O11y and methodologies that make changes easy to back out matter here a lot.

Of course, none of these decisions guarantee success. Moreover, someone will inevitably be unhappy about their favorite tool, language, or service being unavailable. Maybe they’re right — but before you add it in, get the team to consider what they could do to simplify things.