English | EN Reduce Tomorrow’s Rework by Addressing Knowledge Debt Today
Sep 16, 2014
Software maintenance effort usually represents between 50% and 90% of the total budget that companies invest in software engineering activities. Sogeti’s World Quality Report concludes, in alignment with existing studies and software professional experiences, that once a system is released, we usually need to come back to it (for corrective maintenance, evolution, quality assurance activities, etc.). At this point, if a crosswise knowledge management strategy has not been considered, rework may arise, and many times, it may be too late to address it without overcosts. There are several day-to-day examples that fall into this situation: testers that need to recover the requirements in order to know what to test effectively, maintenance people that need to rethink about current and expected system functions behavior, difficult evolution due to loss knowledge, etc. Addressing such situations is a key challenge in many organizations and requires investment strategies when planning software quality activities in a project. The impact of expected “tomorrow’s” rework needs to be adequately considered in advance when performing first-forward development “today”. Therefore, it is necessary to think about which artifacts will be needed “tomorrow” in the likely case that somebody needs to come back to work on the system again for maintenance, evolution or quality assurance activities.
The concept of technical debt has been used in the literature to define and quantify the general impact of rework and its negative consequences when not properly addressed. In this article, we focus on a specific and critical factor of technical debt that is not usually considered in software budgets explicitly, since it is crosswise: the knowledge debt. The knowledge debt appears when the system knowledge is not specified in explicit accessible artifacts but it is spread over different minds that may become inaccessible, or when some parts of such knowledge become unavailable.
Every system manages knowledge about an organization, and such knowledge characterizes the system (requirements), even before the system is developed, but also when maintaining, testing, evolving…. But what happens if this knowledge is not preserved in any form of explicit specifications (functional documentation, requirements models, etc.)? What happens if there is no knowledge repository that makes it available and shareable when needed by others? The answer is that we will probably need to pay an extra cost for rework (due to necessary relearn/recover, harder communication, difficult knowledge transfer…) because of the knowledge debt. If the knowledge debt is not explicitly addressed, it increases as the complexity of the system grows up and as time goes by.
In this context, software projects costs need to be planned in a long-term view. Saving costs today, without considering the risks of future rework due to knowledge loss, may lead to higher costs. Considering knowledge debt risks in advance implies deciding how we will deal with knowledge management in a project and, in particular, how we will specify the requirements for reusing them. This approach implies evaluating present and future investment/costs in an adequate time frame that considers development, maintenance, evolution and QA in the same pack. In other words, we need to adequately balance how knowledge is defined, documented and maintained in our project, by considering “today” and “tomorrow” activities that will probably require this knowledge. Otherwise, we will probably need to pay for rework, aimed at recovering and relearning such knowledge.
In agile projects, the same approach applies, even with more importance. The main key point of such methods is reducing the complexity/risk in each iteration following a “divide and win” strategy. Planning small iterations in terms of smaller processed knowledge reduces positively the risk. However, we even need to ensure that in each iteration, we maintain enough explicit knowledge information in order to reduce the risk of falling into critical knowledge debt, having in mind that we (or others) will probably return to work on the system in the near-future.
As the wide-known sentence says, “It’s better to look ahead and prepare than to look back and regret.”
About the author
