Software quality has been a topic of discussion for years and will likely continue to be for a long time. The usual suspects you’ll find in a textbook or by LLMs would normally be performance, clean code, well-documented, extensible, and some statements about fitting business needs. Let’s examine software quality from a practical perspective, drawing on our experience in the field, working with clients, our projects, and our internal needs of running a small software company.
Great software is output-driven
The main goal of most software is to produce some sort of output. Produce some results that proceed with an action. Knowledge, that again leads to action (or lack of action). It could be a PDF, an email, a dashboard, or some other trigger that leads to change. If one can understand this output from the very beginning, a software team could have great benefits by reverse engineering this output. By focusing on the final destination, you can avoid unneeded features and scope creep. No one likes ending up shaving the YAK. If you don’t get lost on your way to reverse engineering, this can be the way to produce great software that does one thing, and it does this one thing very well.
Home run generator
When software is built with confidence, it spreads. This means that all parties involved feel it. When this happens, it creates inner confidence. This again leads to situations where the software can support users and lay up home runs for different areas of usage. Take sales for example. The software more or less sells itself, and if a sales representative is put on the spot, it’s an easy job to go the whole nine yards. Great software should facilitate home runs for sales, marketing, and pretty much all users that touch it.
Under the hood
Simplicity for the user is a given, but what about what’s under the hood? We believe great software is ready for a due diligence session at any given time. When somebody asks to see your wiring, you get proud and would love to show it. This again leads to software that is ready to move, in any direction. It can be merged, modified, upgraded, or brought over to someone else’s responsibility. Here is a pitfall one can stumble upon with heavy ai-usage. If you depend too much on AI, the only one who knows and understands your code; is the AI.
“Great software is flexible and ready to move. In any direction.”
Great software handles a three-week vacation
Robustness is key, and all team members should feel it. We’ve all heard about deploy Fridays, but I think this is an even better measure. Can the entire team take a vacation at the same time and feel relaxed? You should, and great software should be able to lift you and your family to a great vacation.
When users act like water, the system is ready for it
If you’ve ever built something outside in the real world that should withstand the forces of nature, you’ve probably seen that water can get in regardless of how tight things feel. There is a saying that water dissolves everything (even hard rock!) if you give it enough time. This is a good analogy for how users behave if they come in large numbers. Great software is ready for this type of pressure and stress.
Late to the party
Like in most human endeavors, there are always new shiny things shouting for attention. In software, both open source and proprietary, this is a dense jungle with very loud participants. The forces pulling you toward new (and very often unfinished) technology are strong.
At Octarine, we tend to be “late to the party” and we’re proud of that. In our experience, it reflects our self-belief and confidence that we’re doing the right thing, and that we can do it quickly. We’re placing a bet that we’ll meet our customers’ expectations without going too far in the wrong direction to get there.
YAGNI
Product owners who dare to say no, or “You don’t have a scalability problem. Yet,” are valuable. Along the way, we’ve seen examples of startups that have been straight-up tricked into believing they need an ultra-big enterprise security or data handling setup—when that could not be further from the truth. YAGNI is a principle that also resonates with us in terms of quality. It means “You ain’t gonna need it.” Get real paying customers first. Then we’ll discuss it again later.
Your problem is our problem
We once saw a great quote written on a homebuilder’s truck: “Wish it were ours.” It was something the homebuilders said about the houses they built for clients. They would build them so nicely, robustly, and honorably that they wished the homes were their own. We loved the quote and felt it resonated just as much with software. We feel the same way about the software we build. If we build it for a client, we treat it as our own. To get to this stage, we need to own the problems of our clients. Don’t stop until it’s fixed and you wish it were yours.
Read more about our thoughts on great software in our ongoing blog articles.