When Business Should Care About the Quality of Their Software

The article discusses the importance of balancing technical improvements with visible business benefits in custom software development. It highlights how poor architecture, slow development, and performance issues can impact a business.

Custom software is written to help businesses make money. This is a very simple idea, and I hope that everyone would agree that it is true. Sometimes it happens that we meet business project owners who are more excited about the technologies and coding than about the business itself. But it is a rare case and not the one that helps the project be successful.

In the most successful projects, the business people are focused on increasing revenue while the developers help their customers achieve the right result. Each feature put in the plan is estimated not only in hours but also in the dollars per month it can bring.

It means that if a feature can bring zero dollars but requires more than zero development hours, it gets a low priority or even disappears from the plan completely.

The business should be focused on profit, so why work on features that do not bring in more dollars or at least more users?

Why work on features that have purely technical goals?

Why should one bother about code quality, outdated libraries, or poor architecture, which developers often complain about?

There are several reasons why technical updates without visible benefits may be important.

Invisible bugs

A poor architecture can hide bugs.

By poor architecture, I mean a variety of anti-patterns, like:

• Wrong abstractions — artificial entities in the code that do not represent real life,
• Logic with extreme complexity,
• A large number of modules are tied together.

And many others.

Poor architecture result in a series of interconnected issues.​​​​

• One of them is that developers cannot read the code and understand it completely. Even if they get to understand it at some point, they forget everything in a month. (If they do not forget it, they become irreplaceable experts).
• When developers do not understand the code, they cannot predict software behavior. When they cannot predict the behavior, they do not write automated tests.
• When there are no automated tests in certain places, you may expect surprises.

Here is a real-life example. I had a project that served companies of a certain kind. Each company had an account and clients. Each client had a history of activities with the company.

The clients were people with phone numbers, so they could have relationships with different companies. The way clients were associated with companies was over-engineered, so I told the project owner that we might need to dedicate some time to that part of the flow.

However, that would not bring more money, so the owner did not consider it important.

Until one day, one of the project clients requested a feature that would allow them to see client history. We delivered that feature, and the project owner discovered that some history records contained a mix of activities from different companies. One company could see the activities of the client at other companies.

That was not planned. All of a sudden, the poor architecture turned into a privacy issue — a real bug that had always been there but was just invisible to everyone.

That kind of problem can block development and do some damage to the business.

Slow development

Another potential problem with poor architecture is related to the speed with which the developers can make changes in the existing features.

One of the fundamental books that we recommend to junior developers is Kent Beck’s "Extreme Programming." When I first read this book, I stumbled upon the idea that the developers who work on long-lasting projects should aim to keep the cost of making changes the same as it was when the project started.

In other words, the book told me that the time I would spend making changes in the code should not grow over time.

If there is a feature, I should be able to make changes to it today, tomorrow, in a year, or in three years — and the time spent on that should be approximately the same.

How can that be? - I asked myself. We know that the amount of code grows over time, as does the time needed to make changes in it. But the book suggested that the desired effect was possible, and I told myself that maybe the author had some special experience in knowing how to write code in the right manner.

I think I understand now how this goal can be achieved. It can be achieved through a special modular architecture in which every code block is small and separated from other blocks.

Normally, this architecture is not something that software developers discuss with the business owner. If you have good engineers on your development team, they will maintain the architecture automatically, without telling you about it.

However, this is not as easy as it sounds. The correct modular architecture comes from a correctly designed UI. And a correctly designed UI comes from properly adapted requirements.

I have seen projects that were overly complicated only because the engineering team could not handle overly complicated requirements.

As a result, later changes in their code required significantly more time than they might have needed in the beginning. More development time means more money spent on development and less dynamics in growing the project.

So, it is another technical issue that can cause damage to a business. A solution to this problem is additional effort in making the architecture clean. If you clean the code, you will be able to make adjustments to it faster over time.

Poor app performance

There are certain issues that can hurt your app's performance. Software developers know what these issues are and how to improve the speed of project features. If the frontend makes too many queries to the backend, maybe it is possible to reduce the number of those queries (sometimes optimization requires the opposite — decomposing a time-consuming query into several faster queries).

Or if the backend makes too many database queries, it might be possible to make that part more productive.

A good example of such an issue is the well-known "N+1 issue". Imagine that your application has objects like hotels and rooms. When you want to see all rooms that belong to a specific hotel, your backend makes 1 SQL query to obtain the hotel and then, additionally, it queries each of its N rooms separately. It gives us N+1 queries in total.

Good back-end developers usually know how to find those issues and replace N+1 queries with 2 or even 1 query, which makes the application faster.

However, if the code is too complicated, you can have issues of this kind, but nobody will know about them.

Then, at some point, a few bad lines of the code are copied to another place. Rooms get their own sub-properties (for example, inventories). Eventually, you end up having N+70 queries. (I used to deal with N+700 once). And it takes 20 to 30 seconds for a page to render.

The point is, poor architecture hides some problems from everyone’s sight, while clean architecture can make problems visible — and solve them. This is an advantage project users can actually feel.

Not matching industry standards

When evaluating projects from a business standpoint, many of our customers believe that a large company will eventually purchase their projects.

By the way, some of them have seen their dreams come true.

However, the possibility of that deal often depends on the results of an independent code audit performed by a third party.

If you are one of those people who dreams about being acquired by Nike or Zillow and becoming a millionaire, be aware that there will be a third party company that will get inside your code and start checking the darkest places of it.

They will work hard to find what they have to find.

If there are vulnerabilities hidden, it can be a deal breaker.

As a customer, you want to be ready for any review at any time. If your developer tells you about some sloppy places in the code, some areas that scare engineers off and require unusual time to make changes in, it may be an incentive to pay attention to this part of the project.

Conclusion

The goal of my speculation is not to make the project owner involved in technical questions or — even worse, to make the project owner pursue pure technical goals.

I totally believe that project owners need to focus on their businesses and think about profits. They do not need to go technical. The usual game is, an engineering team can pour a whole lot of technical issues on the customer, and the customer has to put some bounds on the developers in order to keep them within some real-life demands.

But at the same time, it is worth highlighting that there may be a business meaning in tasks that look merely technical.

Sometimes, developers complaining about modules not looking good can point out certain parts of the project that can cause trouble for end users. Their complaints may have something to do with business, they just lack the business sense to tell you exactly what.

To find business value behind technical questions, you can try to collect user feedback about the feature in question, perform additional quality assurance sessions, or just make a note about the feature that needs improvement.

It may take some work, but it will be for the good of the business.

And we will take care of the technical side.

Just let us know.