Principles

Angus Mitchell's photo
Angus Mitchell
·Apr 1, 2022·

2 min read

(If you haven't read the high level overview, Simple x "Never" = Insane, you might want to start there.)

Why am I writing about principles? Imagine your coworker is about to start a project at your company, and I asked you whether he'll do a good job. You'd talk about how he approaches problems, how he thinks about software, what matters to him. I doubt that you'd look at a spec of the project and gauge its usefulness in a vacuum.

We're faced with that challenge -- introduce ourselves as quickly as possible to you, the reader, and explain how we think about software and what we care about.

1. Empower Ops to build tools for themselves

To whatever extent Ops can (safely) build tools for themselves, they should.

Latent demand is real. Ops will build awesome apps, if they have a tool to do it.

2. Don’t tell the Engineers how to do their jobs

Everyone says that it’s impossible to sell to engineers. I disagree. Engineers are discerning buyers. It’s impossible to sell them some bullshit they don’t need.

The other mistake is to assume that the complexity of the engineer’s job is in the IDE or a programming language. This was the sin of the “no code” movement, which may have sullied its name forever. The real complexity lies in the task itself. And that will never go away. You’ll never cut the engineers out the loop, not for apps that do anything meaningful.

The perfect product for an engineer doesn’t add anything. It simply excises annoyances.

3. It's possible to have access/agility AND security/control

All managers want to move fast and be safe. But it’s hard to do both. So managers are forced to pick, making them look like control freaks or undisciplined liabilities.

It’s not impossible to do both though.

4. An app that can be explained in 1 sentence shouldn’t take a week to build

This one isn’t about Ops or Engineering or Managers. It's about all the accidental complexity. “Query a list of failed payments and send an SMS to each user” Everyone agrees that, conceptually, that’s a simple task. But once you start dealing with permissioning, audit trails, guard rails, UI libraries, design, guardrails, authentication, deployment... It's insane! For god’s sake it takes 11 button clicks and raw JSON to run a Lambda in the AWS console. It doesn't have to work this way!

So what are we doing about it?

We're building a platform for bite sized software. The goal: remove as much friction as possible between Engineers and Ops.

 
Share this