There's one constant I've been thinking about in software: we're wrong a lot. It's the nature of our job — we're building systems for people whose jobs we don't know, with tech we're still learning, and whose components are connected in ways we've never seen. We're going to make assumptions and mistakes. Optimize for them!

Rapid Feedback

If you know you're going to be wrong, the best thing you can do is get your software in front of someone who can tell you where you're wrong as quickly as possible. At the core of your process should be rapid feedback. Build the minimum viable product of every feature you build and let your users and customers tell you what works and what doesn't.

Simplicity is King

Simple software is easier to modify when it's wrong. It's also easier to justify throwing out if it's really wrong. Simple is best. Since you're going to be wrong a lot, you should always pick the simplest of any options available to you.

Users also happen to like simple software, but that's another blog post...

Pick Low Friction Tech

Choose tools that let you be productive as soon as possible, so you can find out where you're wrong as soon as possible. This usually means choosing a platform as a service rather than rolling your own super backend. I tend to default to Google's Firebase platform.

When you're wrong with a custom backend, you've got to throw away all the work you did on it, in addition to building out the correct solution. If you had gone with a platform as a service, the cost will be only to build the new correct platform, since you didn't build this super platform in the first place.

Get Good at Being Wrong

Next time you've got a decision to make in your software projects, ask yourself, "What's the cheapest way to be wrong?"