Complexity-quality Matrix

Behold, my mind-blowing graphic illuminating deep truths about software development!

High quality + simple: Amazing when you can do it. Try to stay here. What’s the most straightforward thing you can do? High quality + complex: Can be fine, can be death. Low quality + simple: Can be fine, depending on context, reliability, are requirements met, etc. Low quality + complex: Death.

Just kidding. There’s not really anything new here. Mostly I was thinking about how, in the real world, tradeoffs between complexity and quality tend to turn out kind of linear.

Everyone thinks their software is simple, right? And everyone thinks their software is very high quality.

But you and I have seen plenty of examples of people who insist on taking a lot of time to build complex systems that end up being a pain to work with and maintain. This diagram is my attempt to explain to these people in our lives how we need them to operate.

Look, I’m not saying don’t build something big and complex if that’s what you need to do. Especially not YOU, dear reader. I know that you know what you’re doing, and have the experience and good taste to judge for yourself what’s best.

But in my role providing guidance and feedback to other engineers, my advice will be to stay in the upper left quadrant. Do the simpleset thing you can, at high quality (especially, but not limited to, user-facing quality). Even if you can see a better system.

Once users are getting value, we can always iterate towards that more perfect future.