Why assessing inner software quality is bad for decision-makers (and why customers don’t care anyway…).

 

Please note : This is a translation of an article I wrote over five years ago in German. The translation was triggered by a Tweet from Chris Daniel.

Check my brutally honest guide to handling tech debt. pic.twitter.com/9UoLaxs3zT

— Chris (@wardleymaps) February 3, 2022

During the translation, I changed some contents slightly to improve readability.

Introduction

The inner quality of software systems is seen as increasingly important. Inner software quality – these are the characteristics of the software, which are mainly seen by the developers of the software: good code quality, simple architecture, consistent design, testability, etc.

At the same time, software developers build up more and more so-called technical debt every day – exactly the opposite of inner quality. Technical debt makes a software system harder to maintain, i.e., harder to adapt, more unpredictable – simply more expensive to evolve further. The technical debt metaphor of “(credit) debts” says that you also need to pay interest upon your debt. In the case of technical debt, you’ll pay these interests in the form of ever longer-lasting changes of the software (OK, almost, this kind of “debts” can be “deleted” fast with one keystroke ). As a result, fixing the internal software quality issues becomes more expensive the longer developers wait.

Moreover, in practice, the concept of technical debt is sometimes abused to justify hacks in a software application. “We’ll do that later (when time = money is available)” is one of the most frequently used killer arguments for deferring measures for improving the internal software quality. In this case, technical debt becomes “technical theft” since the intention here is often not to pay back the “debt” anyway but to enrich.

The focus on better, inner software quality is at odds with the constant increase in technical debt. Software developers with a high standard of quality increasingly ask themselves why their customers or boss do not want to have software on a higher quality level. This questioning even goes so far that good software developers increasingly quit their jobs. They hope that other employers will be more reasonable regarding the inner quality of their software products. In most cases, the situation will not be better, just different.

But is there still hope in this regard? To find that out, we take another view on technical debt. More specifically, we take the point of view of people who are also essential stakeholders of software systems: the customer of the software and the decision-maker, under whose guidance developers created software. These two stakeholders are, in the end, responsible for budget/money and can at least authorize qualitative improvement measures if they want. So we need to convince them to get cash for improvements, right? It’s not as easy as you might think!

This article aims to sensitize or disillusion too enthusiastic “quality improvers.” Therefore I try to present (partly extreme and exaggerated!) perspectives on the inner quality of the software. I hope that this will help developers concentrate on other things that are more important for the business instead of fighting battles developers can’t win (and possibly quit or running into burnout out because of so much frustration).

Note: The following explanations are based on standard software, which gets also customized for a select group of customers. Thus, we cover the spectrum between “individual software” and “mass products.” We are also deliberately going into stereotypical extremes to get you starting to think about inner software quality from another perspective.

The customer

Let’s first look through the needs and interests of our customers, for whom we assume that they are interested in high value for low money. We take a look at the following typical point of view:

The software still works

The fact is that there is software on the market that is highly deficient in terms of its inner software quality but still seems to deliver some value to the customer. This is due, for example, to the fact that work carried out manually years ago, including many media breaks, was made considerably more efficient through the use of a “crappy” but custom-tailored software product. This increase in benefit from the rationalization was (and still is) perceived as such a significant increase in effectiveness in the customer’s company that it positively outweighs a few minor software errors compared to the previous possible sources of error. After all, what are a few application crashes compared to lost billing checks? The customer has also become accustomed to the software’s possible flaws and has developed appropriate behavioral adaptations in dealing with errors.

In addition, customers with standard problems are no longer willing to spend immense sums of money on individual software. Therefore, a customer does not see it at all to pay explicitly for qualitatively better software because they are already significantly more productive with the existing software version that is already in use. The existing risks due to a bad internal software quality may then be something a customer (consciously or unconsciously) takes.

Good contract

Procurement on the customer side usually consists of skilled strategists and hard negotiators when drafting contracts between them and their software suppliers. They possess a lot of experience from uncountable tough negotiations with other equally experienced sellers. Now let’s be honest: Most software developers are not the best salespeople. They often sell themselves too cheap. Moreover, they are not selling a physical product with defined tangible characteristics but intangible knowledge that has been transferred into source code. There is simply nothing great to brag about non-tangible items. Perhaps it is also the case that it is hardly possible for seasoned software to describe all of its properties or its range of features.

Modest as software developers are, they prefer to leave these things to other people. That is why software suppliers have the equivalent of people from the procurement department: salespersons. For stereotypical reasons, we assume that they sell everything possible (to optimize their bonuses, of course). Sometimes a piece of software written by a student during his thesis is “marketed” as a highly innovative tool. The ancient, no longer maintainable system gets a new GUI and is sold as super new development. Under the hood, however, the old junk continues to run, which has already motivated quite a few developers to (inwardly) quit. Often, missing features of the software product are coincidentally “in development” (but do not yet exist in reality).

However, procurement on the customer side will manage that the software features that the salesperson presented are part of the contract. This leads to contracts that are far away from reality with phrases such as “everything should work as well as in the old system, only better” or “the extension by <name of a functionality, where neither the customer nor the software supplier knows exactly what it should be> will be provided on <an unrealistic date ending on any month, quarter or year>” – and that at a ridiculous price super offer to make the signing.

The worst thing about this is that the sales department and the executives deliberately agree with such terms. Nevertheless, the hope of profit from follow-up orders after installing the software at the customer’s site still exceeds common sense. But how will it end realistically? The customer is the kind! The project falls behind schedule because the existing system cannot be extended so easily, and the “promised-as-available” functions did not work correctly. The customer threatens with contractual penalties. The sales department appeases and makes the previously hopeful, profitable extensions available again at a ridiculous price or even free of charge to avoid something worse. The customer is always the winner in these situations when they negotiate a contract that is based on the software supplier’s hope (some may call that “risks”). The customer controls the software supplier with such a contract!

Bad internal software quality is even advantageous for the customer since the software supplier has to work for free!

Decision-makers

OK, we can’t expect support for improvements from the customer side. But what about the decision-makers in a software company? For years I believed that it would be interesting for decision-makers (aka human resources with management functions and responsibility for employees) how the inner quality of the software they are responsible for is. I thought that reliable effort estimations were important. I tought it would be great to have great cost predictability enabled by maintainability and analyzability of software systems. I thought that monitoring the inner quality would help to conduct appropriate risk management actions that can avoid significant damages due to contract penalties or gross negligence.

Unfortunately, it doesn’t matter because of the following considerations (among other factors).

Bad quality as part of the business model

The counterpart to the above customer-aspect “contract” is a “weak” buyer or procurement department on the customer side with a “tough” salesperson on the software supplier side. There are maintenance contracts with the customer, or the customer is willing to pay for change requests or bug fixes. So for some decision-makers, it is only a question of contract design to continue to sell their software product successfully. In practice, this can certainly work with loss-leader offers. Once the standard version of the software is in productive operation at the customer’s site, it isn’t easy to switch it off. Any software enhancements that may still be required can therefore be sold at a high price. Vendor lock-in makes this possible.

Unclear basis for evaluation

In order to be able to talk about a quality property at all, it must somehow be presented in a quantifiable way. Here we already have the first contradiction: qualitative properties are not easily measurable (otherwise they would be quantitative). This makes it difficult to find objective measurement tools for inner software quality. Therefore, we often resort to quantifiable properties of the software product (e.g., number of bug fix tickets, number of non-commented source code lines, etc.). However, each of these classic metrics has a different focus on the software product and can also only make limited “valid” (if there is such a thing at all) statements for a specific context.

The fact is that the “quantifiers” of quality are merely heuristics. What is measured is a quantifying proxy for a qualitative property that cannot be measured. This means that the results produced by metrics do not represent “truth” but provide an estimate for what the inventor of the metric had in mind (which hopefully can be well understood). Therefore, there always remains a large room for interpretation of the delivered measurement results, which unfortunately has to be described as “spongy”. Budget decisions on such a spongy basis are therefore tough to make. There are too many other aspects that the chosen metrics may not cover. Therefore, a decision for measures to improve the inner software quality is a high risk. Moreover, measuring the improvement measures is nearly impossible with simple metrics or values.

Transparency as a career killer

What if, after all, the erosion of software was somehow quantifiable? What if the poor quality was communicated to everyone? Then there is a risk of finger-pointing. Other employees could use this kind of transparency as a leverage/weapon, which can be used to their advantage e.g., if there is competition for a better-placed position. The decision-maker who reveals the bad internal software quality of his or her software product also indirectly reveals the bad quality of its management. If the product is junk, the decision-maker’s reputation is also damaged.

Summary

Monetary effects through rationalization, automation, and standardization can no longer be achieved for the customer through the use of new standard software. The potentials have already been lifted by the software used. Thus, customers are not interested in another software that just gets rid of bad internal software equality.

The open and action-oriented evaluation of the internal software quality is poison for each decision-maker. In these cases, measures would become necessary but too expensive to justify economically. In addition, a revelation of the internal software quality represented could lead to a wall of shame for decision-makers.

Tips

After all these negative vibes, there must be ideas, of course, what one can do. And there is! I’ve divided them into two categories: the dark side and the good side:

The Dark Side

• Hire tough salespeople who can prevail over the buyers’ interests (plus point: often, decision-makers are on the buyer’s side. If they bought something crappy, the chances are high that this will not be discussed).
• Use legal advice (maybe even hire dedicated legal counsel) to make contracts bullet-proof. After the initial purchase of the software and gaining trust through “polished features,” a customer should have no chance to switch to an alternative without significant losses (Sunk cost fallacy is your friend!).
• Define only a minimal scope for software customization for a customer. Regulate extensions separately as paid enhancements.
• For demos at fairs, polish only small parts of the application system (e.g., main use cases) and show only these to the customer (kind of an MVP, but just for you).
• Become the market leader (aim for vendor lock-in), then refuse any special requests / customizing changes from customers 

You can take all those risks. But then, please also take responsibility if everything goes wrong and don’t point your fingers at developers. It was your fault!

The good side

• Intelligent software evolution: Delete no longer needed functionality proactively from the application to keep a small footprint.
• Establish replaceability: Design software components and architecture for “replace” instead of “reuse” to keep systems alive incrementally.
• Clarify expectations: Provide a demo app with the current feature set.
• Reduce functional scope: Don’t fulfill every customer junk request, but build competence in customer’s domain of expertise and convince with few features that make customer’s core business immensely more productive.
• Code more intelligently: Code as little as possible, use standard products instead (this makes your programming productivity infinite)
• Business first, technology second: Put technology in the background (don’t accidentally get into the vendor lock-in and don’t block the future by yourself by building purely on today’s trends). The real money is in the software, which optimally supports business processes.

Of course, this only reflects my view of some of the core problems. There are certainly other points of view. What are yours?