Last updated on July 18th, 2021 at 07:13 pm
This case involves deferring a platform upgrade for SharePoint sites. It illustrates the importance of the policymaker’s view of technical debt, as compared to the view that restricts technical debt to the engineering or IT functions.
Background
Growth at the fictional company Unbelievable Growth, Inc., (UGI) has been so unbelievable that there is now a shortage of financial resources. Resources are especially tight for migrating the last groups of SharePoint users from SharePoint 2010 to SharePoint 2013. Consequently, the CFO instructed IT to continue to support SharePoint 2010 for at least two more quarters. Meanwhile, the affected SharePoint users must continue to use SharePoint 2010. Someday, currently set for two quarters from now, IT and the users of SharePoint 2010 will migrate to SharePoint 2013. Both IT and the users might need to expend resources to keep the SharePoint 2010 site operational. Users who make enhancements to their SharePoint 2010 sites will migrate that work to the SharePoint 2013 site. Unfortunately, that might require some rework that would have been unnecessary if the migration had not been deferred.
Discussion
We can regard as a debt UGI’s decision to defer the SharePoint migration. Because it isn’t a financial obligation, we call it a technical debt. UGI must retire that technical debt two quarters from now, when they finally execute the migration from SharePoint 2010 to SharePoint 2013. We can regard the cost of the final migration as the (metaphorical) principal of the technical debt. In the meantime, IT and the users must do some work that might have been unnecessary if they could have performed the migration now. We can regard that extra work as the (metaphorical) interest charges on that technical debt.
The policymaker’s perspective
Some—indeed most—conventional views of technical debt do not regard the deferred upgrade as technical debt, for various reasons—it isn’t software, or it isn’t in a product, or it isn’t a shortcut taken for expedience, and so on. Moreover, the person who made the decision to take on the debt was the CFO, who isn’t an engineer, and who might not even realize that the implications of the decision result in taking on technical debt.
But from the viewpoint of the policymaker, the commitment to execute the upgrade in the future is equivalent to accepting a technical obligation. For the enterprise, it’s a technical debt. Following UGI’s current accounting procedures, the SharePoint users and IT will pay the metaphorical interest on that technical debt. It will appear as an operating expense for those groups. That’s unfortunate, because the purpose of deferring the upgrade was unrelated to their operations. It was an enterprise cost-leveling maneuver. As such, the enterprise should probably account for the costs at the enterprise level to ensure accurate representation of the operational costs for the SharePoint users and for IT, and to accurately represent the CFO’s operations.
Non-technical decisions, occurring anywhere in the enterprise, can sometimes lead to incurring technical debt. Enterprise policy intended to support effective technical debt management must take these phenomena into account.
