Most of the ideas laid out in this pages describe the work I did for my Master's thesis. I am still researching design patterns and the difference between design and implementation. If you would like to hear about my current endevours, my email is firstname.lastname@example.org..
The term "technical debt”, coined by Ward Cunningham in 1992 , describes the cost (which can be measured in terms of dollars or man-hours) that a design decision will cost in the future at the expense of a short term gain. Like financial debt, technical debt is necessary for a product to advance. For example, a software engineer may decide to design a solution that will require reworking in the future. The engineer is aware that it is not the best solution for the health of the system, but it is an intentional decision that must be made in order to meet a release deadline. There was a short term benefit gained by being able to meet the deadline, but in the future the time and effort that was saved will have to be re-invested. In fact, more time and effort may need to be re-invested than if the shortcut was not taken. This additional effort can be thought of as an interest that must be repaid on the gain made by taking the shortcut.
Like financial debt, if a system incurs too much technical debt without a repayment plan, it may become unstable and unable to be modified without significant effort. Ward states “Entire engineering organizations can be brought to a stand-still under the debt load of unconsolidated implementation”. The decision described above to incur intentional debt results in new system debt accumulation which will need to be managed and repaid at some point in the future with interest.
Before a plan to manage technical debt can be implemented, there must first be a way to quantify it. I'm interested in quantifying the impacts of design decay (See next section)
In studying design pattern decay, two key concepts are rot and grime, as identified by Izurieta and Bieman . Rot is the breakdown of structural integrity of a design pattern realization. The term “grime” refers to the accumulation of code that violates the intended role of the design pattern, but does not break the structural integrity of that design pattern. Rot and Grime are mutually exclusive.
Three types of grime were defined by Izurieta and Bieman : organizational, modular, and class. Organizational grime refers to the organization of the files and namespaces that make up a pattern. Modular grime refers to coupling between pattern classes or pattern classes and non-pattern classes which violate the pattern’s intended purpose. Class grime refers to individual classes that make up a pattern.
To facilitate my research, I have created a tool to model grime growth on Java projects.
More details on how this works can be found here.
The code for this can be viewed on my github: https://github.com/melissadale/grime-injector Just a note though, this code is not my finest. It is a prime example of technical debt. I originally had code designed and execution I was very proud of, however I realized last moment it was not working as intended (and also really reinforced the understanding of pass by reference and pass by value). I did what I had to to make it work. I intend to refactor as possible, however it is not at the top of my priority queue.
Impacts of Design Pattern Decay on System Quality(PEER REVIEWED)
Dale M., Izurieta C., "Impacts of Design Pattern Decay on System Quality," 8th ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, ESEM 2014, Torino, Italy, September 2014.
Impacts of Modular Grime on Technical Debt (MASTERS THESIS) The purpose of this research is to study the effects of code changes that violate a design pattern’s intended role on the quality of a project. We use technical debt as an overarching surrogate measure of quality. Technical debt is a metaphor borrowed from the financial domain used to describe the potential cost necessary to refactor a software system to agreed upon coding and design standards. Previous research defined violations in the context of design patterns as grime. Because technical debt can ultimately lead to the downfall of a project, it is important to understand if and how grime may contribute to a system’s technical debt.
I am currently working with the Software Engineering Labs at Montana State University.