Business Imperative

There was a discussion going on LinkedIn and Twitter about technical debt, and management decisions. Sometimes business imperative trumps technical debt, but you must acknowledge the technical debt, and compare the business positives against the technical debt negatives.

Technical Debt

We should probably start by giving a definition of technical debt.  Technical debt is the future consequences from the deployment of a system or piece of software, specifically the negative consequences that we will likely have to find some way of paying back, hence the name debt.  In the cases where the technical debt is too high, we will lose any profit from the endeavor.

Technical Debt

In some instances we have no idea of the technical debt.  Perhaps our product has not been sufficiently developed (we cut corners) nor vetted (tested and evaluated). In these cases weighing the business upside against the long term downside is very difficult if not impossible. Without some information on the product ability we are only guessing the results and any technical debt.  This uncertainty presents a risk that is not-quantifiable (severity and probability) to the customer and our organization.

Perhaps our product has been sufficiently developed we did not cut corners, and we tested and we have seen no failure (or have corrected all defects) of significance from our testing and product experience.  That does not mean that there is no debt, but it does mean we have explored to understand what debt we may have in the future, the risk is perhaps less since we have actually explored the product before sending it off to the world.

Guess Work

When we attempt to assess technical debt in the absence of tangible results we are only guessing.  Decisions about the consequences of launching and the technical debt we just incurred are unknown.  We may find the decision to launch without considering the technical debt comes back as queries from management; we are spending too much on field quality, with finger pointing and demands to make things better.  These waffling demands can make the employee feel as if they are flotsam being cast by the shifting tides.  Not to mention some of these conversations may seem as if management is casting blame or castigating employees as the cause of the situation.

Summary

Work to understand the technical debt, knowing there is plenty of uncertainty.  If you have to make a business decision regarding launch that leaves plenty of uncertainty in the product, do not go back to the employees working to meet the objective with “it is your fault attitude”

If you are interested in learning more about software testing follow this link https://valuetransform.com/training/login/index.php create  profile and I will add you to the software testing online class.