7 Signs of High-Quality Software That Business Stakeholders Can Understand

As the saying goes, an ounce of prevention is worth a pound of cure. The best way to ensure that your custom software is built with high-quality code and architecture, is to hire a Software Architect ‑ not to be confused with a Solution Architect ‑ to provide oversight throughout the development process, and then give this person the authority to make decisions over implementation issues. But if your software has already been delivered then you’re past that. So, now that you’re here, the question becomes how do you know if it was a job well‑done? In this article we examine seven signs that indicate the software that was developed for you is of high quality.

#1 – Development is Relatively Fast

No software is ever “done.” There are always new things to be added so development is an ongoing endeavor. However, you can begin to see this sign show up in the last third of the development process for the first version of the software. As such, there are two circumstances where you can observe this phenomenon. The first circumstance is toward the end of the development of the first version as previously mentioned. The second circumstance is when there is ongoing development after the first version has been delivered.

In those two situations, if development of new features is relatively fast, then this is an indication that the software was designed well. However, as with most things in life, it depends on what the nature of the development is.

If the new development is just another version of something that has already been done, then chances are it will be implemented quickly because it’s just the addition of the same old type of artifact. Creating a new table of new and different data to be shown on a grid when the software already has other screens with data grids is not the kind of indicator you’re looking for.

If the additional development is for a feature that is new, different, and unanticipated, yet the implementation of this new feature is relatively fast, then kudos to the engineers as this is an indication that they did a good job on the internal architecture and code quality.

#2 – Development is Relatively Easy

Relatively fast and relatively easy typically go hand-in-hand but that is not necessarily the case. It is possible that development for a feature could be completed in a couple of days, but it may have taken significant effort to make sense of and to reason about the complexity of the development for said feature. How do you know if the developer had a hard time with it? Well, here’s a tip.

Borrowing a concept from the game of poker, developers have a tell.

When going over the requirements for a feature, typically discussed in a Sprint Refinement session if you’re using an Agile process or any meeting where the business stakeholder is explaining the need, developers will talk about the technical aspects of what needs to be done and that’s where they reveal the signs. In other words, developers tend to think out loud when giving feedback about a requested feature and behave in ways that can give you a clue.

This can be annoying if you don’t care about the details when a simple, “yes I can make that happen” is all you need, but if you pay attention to body language, facial expressions, and the number of concepts they mention (who cares what the concepts actually mean), then it will give you an idea of how much of a pain it is to implement the feature.

While observing this interaction, if the developer’s murmurs are short-lived, the number of concepts spoken of are few, they quickly reach a point that they confirm it can be done, and - this is the most important part - the requirements are at least fairly complex, then this is an indication that the software was developed with good architecture and high-quality code.

Basically, if you know what you’re asking for is kind of a big deal, you’re braced for tough news in terms of time and cost, but then you’re surprised to learn that the development effort will be easy, then this is a very good sign the software was built with good architecture and high-quality code.

One important thing to keep in mind before you take this idea to the bank is that sometimes development is a pain for reasons that are out of the developers’ control. For example, if the feature requires pulling data from some source that is problematic, then the complexity increases because of the weakness in the architecture of the source system. Sometimes, the requested feature is truly complex in nature, and it is the nature of the ask that is complex and not because of the quality of the code. So, take this one with a grain of salt and be aware of external influences that are not in the hands of the developers.

#3 – Estimates Are Consistently Under 20% Error Margin

This one is a tough pill to swallow for business stakeholders. How is it possible that going over up to 20% in time and budget is considered a success? Well, let’s consider some context first.

The 20% error margin is easier to deal with when we’re talking about an internal software development team of a large corporation. If a project is estimated to take five months to complete and it is completed in six months instead (i.e., 20% over), then for the most part this is considered a success as the additional time and cost in large corporations is rather commonplace. In fact, large corporations rarely see projects actually finish within that margin of error. There are many reasons for this that are out of the scope of this article.

Smaller businesses have a harder time absorbing this cost, which is why it is better to mitigate that risk by accounting for up to a 50% spill over time and cost. This is the unfortunate reality but, in this article, we are discussing how to judge code quality after most of the software has been delivered or you’re past the first version and in the midst of ongoing development. Therefore, at this point you already know if you’re over in time and/or budget.

If on average the estimates for the features being developed are delivered in under 20% margin of error consistently, then this is a sign that the software was built with good architecture and high-quality code. This coincides with points #1 and #2 above as well and as previously mentioned, this is only a good indicator for features that require things that are in the developers’ control.

#4 – No Maintenance or Maintenance is Minimal

If software requires regular maintenance, then chances are something is off. Adding new features is a development exercise, not maintenance. I’ve seen software that constantly needed a developer to intervene to keep it working. Sometimes it was unanticipated data values that would break things. Sometimes it was data getting out of sync. Sometimes data sets were too large causing performance problems. Sometimes the way a user did something caused a problem, which is not the user’s fault. There are all sorts of issues that can happen that requires the developer to take a look, troubleshoot, and then resolve. If this happens and the issue typically takes minutes or hours, stakeholders might chalk it up to “maintenance,” but know that this is not good.

Your software should just work. It should simply do the things that it was designed to do. Except for the occasional hiccup, if the need to do things to maintain the software is minimal and rare or better yet unnecessary, then it is an indication that it was built with good architecture and high-quality code.

#5 – New Team Members Become Self-Sufficient Quickly

This tip is a hidden gem. If new developers join the team and they are able to ramp up quickly allowing them to become productive soon after joining, then this is a very good indication that the software was built with good architecture and high-quality code.

Why is that the case?

When software is designed well, it exhibits some or all the characteristics listed below that make it easy for a newcomer to learn their way around the code thereby enabling them to contribute sooner.

• Architectural principles, standards, and best practices are honored
• Well-known design patterns are used appropriately
• Artifacts have good names that accurately describe what they are and/or what they do
• Unit tests are well-designed, concise, and have a high degree of coverage (i.e., most of the code is proven through unit tests)
• Tech debt is low
• Understanding is not dependent on “Tribal Knowledge,” which are things that cannot be ascertained without the explanation of a human being who “knows how it all works”

Books have been written about these things. It takes an extraordinary amount of knowledge and experience to ensure that software is built with all those characteristics. When the software is built in a good way, one of the great benefits of the solid architecture is that new developers will find it easy to learn how it works and be productive developing new features very quickly.

On this point, keep in mind that it also depends on the skill, aptitude, and experience of the developer so your mileage may vary.

#6 – Little-to-No Production Issues with Unforeseen Data and Usage

You can do everything you think you can to prepare for prime time but when the rubber meets the road, the reality of the world takes over. It’s just not possible to predict every way that users will think about the system, the way that users will operate the system, or what data users will attempt to enter into the system. However, there are techniques to mitigate these risks, which is why this tip can serve as a good indicator for you.

If the software gracefully deals with unforeseen data and unforeseen ways that users operate the software, then that is a good indication that it was built with good architecture and high-quality code. This doesn’t mean you won’t see errors happen. In fact, good software should produce errors when appropriate but the errors should be caught by the software code and served up in a way that is meaningful to the user so that it is clear why something happened and how to resolve it.

#7 – Unanticipated Use Cases Can Be Easily Accommodated

This is arguably the best indicator of good software design. If the previous tip is a hidden gem, then this one is a pearl.

If a new feature, tweak, business rule, or restriction needs to be implemented, and the developer can accomplish it with configuration, then that is a strong indication of good architecture and high-quality code. When a business problem is well- understood, a good Software Architect has the foresight to anticipate the possible directions that the software can go and then design it with the future in mind.

Unfortunately, this is something that is vastly overlooked and woefully underappreciated.

If a stakeholder needs something done, and the developer says, “no problem we can just change the configuration and it will behave as you requested,” and nobody bats an eyelash after hearing that? Then you don’t understand the value of what you have and that is a crying shame.

When this happens it should immediately catch your attention and you should probably pick the developer’s brain as to how it became so easy to do that. Then try to wrap your head around how significant this is, especially if the thing being requested isn’t straight forward. It takes extraordinary skill to build software with a large codebase and then be able to easily add new things later on before anyone has asked for it through configuration no less. To nail a design this well is rare and cannot be done for all things in a software product, but when it happens it is noteworthy and should be celebrated.

Conclusion

Writing software for business is incredibly difficult and complex. The business landscape is ever-changing based mostly on the whims born from the creativity of the human mind. There are infinite ideas that humans can conjure up at any given moment. Add to that what competitors are doing, where the market is trending, what your customers want, and systemic issues like the overall economy, politics, and war, then what you have is an environment that is extremely unpredictable. Anything can change at any given point in time, so writing high-quality software under these circumstances is supremely challenging to say the least. For these reasons, it is important for layman to have an understanding and an appreciation for well-designed and well-written software.