The most common issue in software is usually not how to build things but building things that are not useful. The same can be said of most companies - it is usually not how to do the thing but whether that thing is worth doing.

This phenomenon is often called The Build Trap and is why I'm writing this post today - to emphasize Solutions > Systems.

Focus on Impact

My best advice for any software engineer is to focus on impact. This is the best 3S Solution I've found to avoid the Build Trap and thus is generally a good thing to optimize for.

The end goal of a system is always impact. We are building it to do something - solve a problem and / or capture an opportunity. Software is simply a means of doing so - a tool in our toolbelt.

The end goal therefore is never to build a system or to build software (an output) but to achieve some outcome and do so with the highest possible ROI - Impact for Cost.

Simple Scalable Systems as Solutions

I've talked about Simple Scalable Systems (3S) a lot here in the Lab. I do this because I think it's a great rule of thumb for measuring a system's quality and generally outperforms other types of solutions over time and iterations.

But I recognize that a System is only as good as it is useful. Over time I've witnessed many frameworks used incorrectly and thus fail to live up to their own potential.

An example of this is the term Minimum Viable Product - MVP. It is so ambiguous that a majority of ppl do them incorrectly. Minimum Viable Experiment (MVE) is a better version of this.

I believe Simple Scalable Systems (3S) is great for the implementation portion but implementation is never enough. We need to take into account the context we're working within and the impact we plan and actually achieve.

So I'm walking back 3S a bit and trying to put it in context - it's best used as part of a solution - 3S Solutions.

My hope is that this new context makes the goal more clear and reduces resulting misuse and inefficiencies.

Next

3S (Simple Scalable System) Solutions are the best way I've found for finding and building impactful software systems at scale - across domains and tech stacks. So I'll keep creating and sharing them until I find a better method.

Q: How do you rate the quality of software? What are your rules / systems for consistently building useful software?

If you liked this post you might also like:

• Simple Scalable Systems - How to find 80/20 Silver Bullet Solutions for any domain
• Escape the Build Trap (The simple way)
• 3 Tips to be an effective Software Engineer (with less work and more fun)