Policymakers whose areas of expertise have little or no overlap with software engineering might be at a bit of a disadvantage when the conversation turns to refactoring. That can happen when the matter at hand involves software assets that carry technical debt, because the engineers are likely to argue for resources and time to be set aside for refactoring. Other “re” words are also likely to pop up: restructuring, re-architecting, rewriting, replacing, repairing, retiring, retreating, and re-engineering are examples. Some of these are clear—and clearly unaffordable—but some are less clear. What’s needed is a lucid explanation of refactoring for policymakers.
To refactor1 a software asset is to improve its internal structure without altering its external behavior [Fowler 1999]. The improvements usually relate to maintainability or extensibility, and for software, that usually requires improving the readability of its code (for engineers), though it might entail some minor changes of other kinds. Instance by instance, these improvements are usually small in scale. Even so, a refactoring effort might involve small changes throughout the entire asset or throughout an entire suite of assets.
Although we usually regard refactoring as a software-related activity, refactoring, like technical debt, is a concept that can apply to any technological asset. To render the refactoring concept useful for assets other than software, we must be a bit more precise about the effects of the changes involved in refactoring.
A more general definition of refactoring
Refactoring an asset inherently changes that asset; what distinguishes refactoring from other kinds of changes is the observability of the changes. For the definition of refactoring used in software engineering, the changes are observable only to the software engineers who maintain or enhance the asset.
Here’s a definition of refactoring that’s somewhat more widely applicable:
To refactor a technological asset is to apply a series of small, behavior-preserving changes to improve the structure of the asset in ways that have effects that aren’t ordinarily observable externally. When effects are observable externally, they’re very specific, usually related to attributes such as quality and usability.
For example, after a municipality replaces incandescent traffic lights with LED traffic lights, there’s no effect on traffic control. To the untrained eye, or to the trained eye that’s otherwise preoccupied, the change isn’t noticeable. But those responsible for signal maintenance or for monitoring operating costs will notice significant advantages. With respect to traffic flow, we can therefore regard the change to LED traffic lights as a refactoring of the traffic control system.
Refactoring in manufactured consumer items can be more difficult to recognize, because the useful life of the item so often ends while the item is still in the hands of the consumer. For example, we might ask how to refactor a certain subassembly of an automobile that’s already in service. Some writers have identified the vehicle recall as a kind of refactoring [Shroyer 2016]. But I prefer to regard successive models of manufactured items as containing refactorings of earlier models.
For example, in robot vacuum cleaners, the iRobot Roomba is now available in a ninth-generation “series,” though the exact number of the generations depends on what one counts as first-generation. In laptop computers, most manufacturers’ offerings do change from one model to the next version of that model. Some of these changes are more significant than what we might consider to be refactoring, such as Apple’s removal of the MagSafe power connector [Spence 2018]. For laptops, more likely to be a refactoring would be a change to a slightly more efficient internal fan.
Other applications of the refactoring concept
The refactoring concept can also apply to processes. Indeed, failure to refactor business processes is sometimes a cause of needless complexity, high maintenance costs, and other difficulties in technological assets that must interact with processes that need refactoring [Distante 2014]. The refactoring concept—that is, to improve internal structures while preserving external behavior—might even find use in organizational restructuring and debt restructuring.
Endnote
[1] One might wonder why this process is called refactoring. Martin Fowler, the author of the classic 1999 book about refactoring, has investigated the etymology of the word and concludes that it likely arose in the Forth and Smalltalk communities in the 1980s. [Fowler 2003] Jump back to the text
References
[Distante 2014] Damiano Distante, Alejandra Garrido, Julia Camelier-Carvajal, Roxana Giandini, and Gustavo Rossi. “Business processes refactoring to improve usability in E-commerce applications.” Electronic Commerce Research 14:4 (2014): 497-529.
Available: here; Retrieved: August 23, 2019
[Fowler 1999] Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Robert, Erich Gamma (Foreword). Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley Professional; first edition (July 8, 1999).
[Fowler 2003] Martin Fowler. “TechnicalDebt,” blog entry at MartinFowler.com, 1 October 2003.
Retrieved January 2, 2016, available at here; .
[Shroyer 2016] Alexander Shroyer. “Refactoring Hardware vs. Software,” Hoosier EE Blog, July 17, 2016.
Available: here; Retrieved: August 22, 2019
[Spence 2018] Ewan Spence. “New MacBook Pro Leak Reveals Apple's Innovative Failure,” Forbes, June 7, 2018.
Available: here; Retrieved: August 22, 2019
Other posts in this thread
- Retiring technical debt in irreplaceable assets
- Technical debt retirement: where is the technical debt?
- Rules of engagement for auxiliary technical debt
- Legacy technical debt retirement decisions
- Retiring localizable technical debt
- Controlling incremental technical debt
- Automation-assisted technical debt retirement
- Outsourcing Technical Debt Retirement Projects
- Refactoring for policymakers
.JPG){kind=link}