Transparency in organizations has tremendous benefits. But it doesn't come for free. Let's take recruitment process as an example.

If there are only 2 autonomous decision makers, then the process is simple. They screen CV, meet the candidate, have conversation, check the tasks that the candidate was assigned, may have a quick follow-up to and that's it. Usually this is enough to make the decision. Feedback can be given to candidate even immediately if recruiters are experienced.  In case of 1 decision maker it is even simpler, but it's usually good to have at least one more opinion.

But what if we would like to make that process transparent? Score the candidates by measuring them somehow to show where the decision comes from? It may be easy to measure A/B/C test score, financial expectations and years of experience, but not everything is so quantitative. Measuring personality, value of the experience for the company, attitude, personal growth potential or some creative task may be tricky. It may require to create complicated recruitment process and metrics to justify the final decision transparently.

What are your opinions? Is it worth to invest in transparency in this case? Or it's better to trust the decision makers and just have informal notes about the candidates? Have you ever wondered what should be the proper balance?

Albert Einstein said that everything should be made as simple as possible but not simpler. Simplicity is the holy grail of IT and also of business. It needs smart thinking and often experience to make complex things simple. But how about the other situation, when things are simpler than they should? In that case we are creating technical debt.

In finance debt is not always bad. When debt contributes to generating higher income and cost of interest is lower than that income, then the debt is healthy. For example when company makes a loan to modernize its equipment to be more competitive and generate bigger revenue - then we consider that loan as a good investment. Of course there is always risk involved and we usually cannot be sure about the future revenue but that's another story.

How about IT projects? Can technical debt be also good?

Examples of good technical debt

Debt is a shortcut to generate revenue quicker. IT projects are no different. If a quick and dirty implementation will be enough to acquire the customer which will bring income - debt is acceptable. It is better to have quick and dirty implementation which generates revenue than missed deadline and lost deal. However, income should be high enough to pay the debt later. Introducing big technical debt to have little income is probably not a good move.

An example of good debt may be building a prototype. Prototype is something that we should afford to throw away when it turns out that the idea is not worth continuing or there is a better approach to continue it. Prototypes are great for demos and idea testing. However, when the prototype is approved we should keep in mind that it will usually require a significant refactoring or even building from the scratch before it becomes the final product. In other words - the debt will need to be paid back. Good software development practices may help to reuse significant part of the prototype in the final product.

Another example of a good debt may be hardcoding some logic. Hardcoding is always a concern for software developers because it means that the created solution is not flexible and may need more work in the future to introduce changes. But over-engineering is as bad as over-investing. When we don't need flexibility, let's not introduce it just in case. Postpone any work as long as possible. It may require some rework in the future but we may also have bigger budget in the future. Paradox here is that what means debt for technical team may be savings for business team. To avoid technical debt in codebase, business may need to make real debt to cover development costs. Usually it is better to have debt in codebase rather than on bank account. Good software architecture will allow to pay technical debt much easier that to pay real money back to the lender.

Debt management

Technical debt as any other debt has to be manageable. Stakeholders and the team need to be aware where the debt exists, how big it is and what is the interest rate. Interest from technical debt is paid by having lower productivity. Teams spend time on investigating how system really works, fixing bugs, manual configuration and manual testing. The more time is needed for those activities, the higher is the interest rate. It is really bad when the cost of this time is not covered by the revenue that the product generates. But even when that cost is covered, companies should be paying back technical debt systematically to have proper level of productivity which allows to stay competitive.

How to manage technical debt?

1. Measuring how much time is spent on system maintenance.

Management teams are often not aware how much time is spent in this area and therefore don't have numbers to understand how much it costs to pay the interest for technical debt.

2. Using tools to measure code quality and automated tests coverage.

That tools are usually easy to integrate with development pipeline and help to identify technical debt. They provide deep insights into codebase but are not saying if the identified debt is good or bad.

3. Mapping reported issues to specific areas of the codebase.

It helps to identify which parts of the system generate highest interest for technical debt. Some parts of the system may have poor code quality but there are no issues in terms of maintenance.  It is like having 0% interest loan. Other parts may have great code quality and 100% test coverage but they are generating a lot of issues because of wrong logic, missing requirements or lots of manual actions involved. It shows that interest can be paid not only because of poor codebase but also because of poor requirements specification and business analysis. Usually it goes together - when requirements are messy then the source code becomes messy.

Sumamry

What are your opinions? Do you agree that technical debt can be good? Can you give any more examples of good technical debt and how to manage technical debt?