The ghost ramps of highway I-695 in Somerville, Massachusetts. Photo (cc) Nick Allen.
Interstate 695 was planned in 1955 as an “inner belt” circumferential route in Boston and adjacent towns. When cancelled in 1971, construction had already begun. The cancellation thus resulted in an incomplete implementation.
Newly constructed roads and mass transit now use the rights of way that were the original paths for I-695. Some never-used structures remain to this day, including a “ghost ramp” in Somerville that would have connected I-695 to I-93. Because this ramp is a mere stub that begins on an elevated stretch of I-93 and ends in mid-air, barriers across the stub entrance prevent accidental use. The ghost ramp constitutes technical debt because it’s an incomplete implementation. Google satellite view
For safety reasons, regular inspections, maintenance, and insurance are necessary for the ghost ramp. But it provides no utility and serves no civic purpose. Because the cost of retiring this technical debt—namely, demolition costs—would likely exceed the present value of the lifetime costs of inspection, maintenance, and insurance, the ghost ramp remains.
Sometimes, the best way to deal with technical debt is to leave it in place.
This case illustrates how a decision to incur technical debt in one part of an organization can burden other parts of the organization with the metaphorical interest charges on that debt. To gain effective control of technical debt, it’s probably necessary to hold accountable those who make the decisions that lead to incurring new debt.
This case illustrates the importance of recognizing as technical debt any artifact whose condition or absence contributes to a loss of organizational effectiveness or agility. It describes a situation related to software development, and which some would argue isn’t actually technical debt.
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.
Here’s an example of using the technical debt metaphor to think about how elements of a hardware asset can limit the ability of the enterprise to attain and maintain market leadership. The asset in this example is the trackbed of Amtrak’s Acela Express.
