Technical debt in a rail system

Last updated on June 14th, 2018 at 08:24 pm

Acela Express rounds a curve in Connecticut
Acela Express rounds a curve in Connecticut. Shown is the trailing power car of a southbound Acela Express and the front of a northbound Metro-North railcar.

Most definitions of technical debt require that the asset bearing the debt be software. From the policymaker’s perspective, this requirement is rather limiting. So for the purposes of this blog, I define technical debt as any property of a technological asset that we would like to revise, replace, or create, and which limits the ability of the enterprise to gain or maintain a dominant market leadership position.

Consider an example from the railroad industry. In the United States, the highest-speed rail line is Acela Express, which travels in the northeast corridor between Boston and Washington, D.C. Parts of the right-of-way, track, and catenary it uses were not originally designed for this application, and therefore trains cannot operate at their highest possible speed [Maloney 2000]. On the 231-mile section from Boston to New York’s Penn Station, Acela achieves an average speed of only 63 mph (101 km/h), even though the trains can operate safely on straight track at 150 mph (240 km/h). Yet, Acela still manages to capture a 54% share of the total air and rail market between these two cities.

That 54% share might be higher still if not for technical debt. To compensate for centrifugal forces as Acela Express rounds curves, its passenger cars are able to tilt the passenger spaces to enable the train to round the curves at higher speeds than would otherwise be comfortable for passengers. In effect, the cars “lean into” the curves, just as a running athlete leans when making a sudden change of direction. Although the cars were designed to be able to tilt by as much as 6.8º, the adjacent set of tracks is too close to permit this without risk of collision with trains on those tracks. The maximum tilt is therefore set at 4.2º, which, in turn, reduces the maximum speed consistent with passenger comfort that the trains can attain on curves. The technical debt manifested in the tracks Acela Express uses thus prevents it from offering a service that would be more competitive with alternative transport modes, especially airlines.

Note: In August 2016, Amtrak announced that it will be upgrading its trainsets and tracks to exploit new technologies, including active tilt technologies. All existing trainsets are due to be replaced in 2021-22.

References

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

Related posts

Technical debt in the highway system

Last updated on December 11th, 2018 at 11:26 am

The ghost ramps of highway I-695 in Somerville, Massachusetts
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 it was cancelled in 1971, construction had already begun. Rights of way that had been cleared have since been reused for roads and mass transit, but some never-used structures remain to this day, including a “ghost ramp” in Somerville that would have connected I-695 to I-93. This ramp, which is a mere stub that begins on an elevated stretch of I-93 and ends in mid-air, and which is blocked off to prevent use, constitutes technical debt in the form of incomplete implementation. Google satellite view

For safety reasons, the ghost ramp must be regularly inspected, maintained, and insured, but it provides no utility and it is not used for any 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.

References

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

Related posts

Case 1: A platform upgrade

Last updated on November 21st, 2017 at 08:35 am

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
File servers in a rack
File servers in a rack. Photo (cc) Abigor courtesy Wikimedia Commons.

Growth at the fictional company Unbelievable Growth, Inc. (UGI) has been so unbelievable that there is now a shortage of financial resources 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 be required to 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 need to migrate that work to the SharePoint 2013 site, and 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 is not 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 policy maker, the commitment to execute the upgrade in the future is equivalent to accepting a technical obligation. For the enterprise, it is a technical debt. Following UGI’s current account procedures, the metaphorical interest on that technical debt will be paid by the SharePoint users and by IT, and 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 whose costs should probably be accounted for at the enterprise level to ensure that operational costs for the SharePoint users and for IT are accurately represented, 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.

References

[Maloney 2000] Brenna Maloney and Don Phillips. “All Aboard AMTRAK’s Acela,” The Washington Post, November 30, 2000.

Available: here; Retrieved April 18, 2017.

Cited in:

Related posts