RefactorKit - Abstract

1 minute read Updated: September 21, 2019

I had written this abstract for Dr. Antonio Martini before we were supposed to meet up at TechDebtConf 2019 in Montreal. I unfortunately could not attend the conference, but I had sent this to Dr. Martini via email. Here is the original abstract of the RefactorKit concept.

Refactoring is defined as the process of improving the internals of a codebase without affecting exterior functionality. “Technical debt” is a common financial metaphor for understanding the health of a codebase, where the principle is the time and costs of refactoring and the interest is the additional ongoing effort expended due to decayed code quality. Architectural technical debt (ATD) has been defined as significant system-level technical debt which require more investment to pay the principle and thus require careful decision making strategies. ATD has been described in existing literature from the lens of decision theory, in order to develop strategies for predicting and making a decision with some degree of confidence. In this document I propose there exists a set of desired outcomes for development teams which are not fully dependent on the degree of correctness of the actual decision being made. Outside the lens of decision theory, there exist social and cultural effects of refactoring which I propose are of primary concern to development teams. Furthermore, I describe the process of developing these outcomes from the lens of job-to-be-done theory and an associated applied methodology for product and service innovation. This innovation process reverse-engineers many of the same classifications seen in the existing literature, and is used to develop measurement systems for development teams from a social and cultural lens. This innovation process produces an end-to-end perspective that could assist technical debt practitioners and researchers with the development of ATD management tools. I apply the process to define and describe the requirements of a product for development teams called RefactorKit, and finish by exploring topics for future research.

That’s it. More posts about RefactorKit are available on the blog. I will later edit this post with the links.