Technical debt is like any form of debt. It originates from any action taken now that requires a future action to cancel or mitigate it. Technical debt appears in every product approaching obsolescence. It impacts every stage of the product S-Curve; but it often relates most to the late majority and laggard adopters. By these stages, the early adopters and early majority adopters have already recognized the debt and are taking actions to enhance, modify, or replace those capabilities that limit the viability of the system. Technical debt exists, but its implications are often not recognized until later in the product’s acceptance.
In software, where the term appears to have originated, technical debt is an implied cost due to a need to fix or resolve an issue that was intentionally, or even unintentionally, applied to the code base. It is associated with a compromise or trade off that saves complexity, difficulty in implementation, or project or budget time, but this action embeds a need for later corrective action. This then shows up directly in software maintenance and support. Technical debt is visible in the program budgets and code development needed to enhance, modify, or replace those capabilities. It can be associated with software agility, code extensibility, and even usability.
Technical debt just like monetary debt accumulates “interest”. Over time the failure to address this technical debt results in code, information, processes, and other portions of the system to accumulate this debt and to compound it over time. It is not difficult to imagine the technical debt built up over time when we look at the escalating costs of the software we use every day. It is also not difficult to imagine how hard it is to recognize this since the concept usually is not recognized until we are years into an implementation.
The interest from technical debt is most visible today in the large bodies of software code resident in government systems, large box retail and inventory systems, and other large “mainframe” systems. A quick view of the U.S. government’s annual budget demonstrates this when multiple billions of dollars are in Information Technology and upwards of 90% of that budget is to manage the existing systems.
MORE BY MICHAEL R. COLLINS
These systems are built upon old code bases and because they are older and “working functional systems”, they are considered “stable”. Yet, they still need to be maintained and every new twist in an operating system, compiler, or modification may need adaptation of the older code base. In order to enhance, modify, and replace any part of the code base to achieve new capabilities, these portions of code are often just “wrapped” in newer code and user interfaces.
Usually, this code base is not updated, and when the body of experts that know and understand the code base has shrunk or is only available off shore, technical debt becomes almost insurmountable. Further, because of years of failed or aborted changes the modified code resides in place and is either stubbed off or truncated but left in the body of code. Maybe, at a later date, this code reappears. In fact, newer capabilities like Internet of Things and Security (encryption and other tools) are inhibited by this relatively open access environment.
There are few, if any, bodies of code, especially in the large code sets identified above, that anyone knows how they operate, end-to-end. There is no real knowledge of frequency of operation by sequence, isolated historical paths that might write data, or less frequently used paths developed for special purposes, etc. These ambiguities and hidden code are hidden vulnerabilities and sometimes have resulted in system penetrations. They are also an avenue and the mechanism for insider threats to obscure and hide their actions.
Digital farming will have technical debt in the framework of its code base, as well as in the digital twin that it manages. The architecture developed will tend to mitigate the early debt and, depending upon the agility of the code, it will delay debt for quite some time. Each of these cases, debt in the code base and in the digital twin, are separate and distinct. The code base technical debt is buried in the code that defines its operating system and its digital twin. This technical debt is embedded and mitigated by the code developer in the code architecture, its maintenance environment, and its support structure. This is the typical understanding of technical debt. This software code variant of technical debt enjoys a wide body of discussion, and in many ways the minimization of technical debt for this aspect follows from the characteristics of the viable digital offering.
Just how does this apply to agriculture and the digital twin? First, any decision can result in technical debt and it doesn’t have to be limited to software. A decision to buy equipment, or not, a decision to mitigate, or not mitigate, a stress in a field, and even a change in algorithms that define an aspect in the cultivation, all result in a persistence of that decision in that location in that field.
For example, if this is a chemical applied, a stress unresolved, or a decision made the result often has a future decision need. This decision to monitor and report on the chemical applied and track its persistence in the soil is a direct measure of technical debt. This decision may result in a future weed, fungus, or insect stress that spreads to a broader area of infestation, or it may be a course of action that compromises the stewardship of the land or environment, like fertilization or irrigation. It may be the build-up of toxins and other chemicals in the soil. The issue here is not to determine whether the action is good or bad, but rather to recognize that the decision may result in yet another decision, now or in the future.
Again, in this case the issue is not to adjudicate good or bad, but to recognize the debt. One thing that the digital twin is going to be very good at is its ability to remember and recognize the debt in the cultivation across the temporal analytics of time. In fact, we are counting on it.
The digital twin must remember every aspect of the field. The nature of its topography, the boundaries and artifacts, the soil and its horizons, the crops and chemicals applied, the stress threats and yields, the hydration and nutrient dynamics, and every aspect of the productive asset. We want the digital farm to remember and remind us of these debts, and to suggest their importance.
The technical debt is not just a data element. It is also the required mitigation. Too often the debt is all that is recognized and the mitigation is ignored. In digital farming, the debt becomes a complex time series analysis, something every grower does instinctively every day. Technical debt is also a late adopter cycle concept; we don’t recognize it until it is well embedded in our system. For the field, we might not recognize it until it is well past too late. This debt needs to be more visible earlier.
Unfortunately, the size of the fields, the complexity of the problem, the fidelity of the debt presentation, and other external factors are beyond the grower’s individual capability and the processing is still outside the decision cycle of the contemporary systems. In order to be effective in managing the technical debt of the farm, the digital farming system needs to automate the aggregation and analysis of debt, and all of its interest. In order to embed real stewardship in the farm, we need to remember, analyze, and inform the grower.
In agriculture, technical debt is the residual soil memory of past actions that may bear on the decisions today. While technical debt in the code base may be a negative, technical debt in the soil may be even bigger, and a viable digital farming solution will provide the memory, analysis, and alarming to the cost of and need for mitigation.