In software-intensive systems, technical debt is a design or implementation construct that is expedient in the short term, but sets up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.
Hello everyone! At long last, attached is a distillation of the research roadmap, based on discussions and sessions at the Dagstuhl seminar. Please take a look and add any comments and thoughts. This remains to be shaped and fleshed out by you, the research community. As part of that process, we plan to spend part of the MTD workshop in Raleigh, NC, next month, on this subject.
Here are the slides presented during my lightening talk :
Remediations in SQALE-Dagstuhl
As requested, the definition that Ipek presented is below. Feel free to refute, extend, show gaps, etc. in the comments so we can improve:
Technical debt as a software design issue that:
- Exists in a system artifact, such as code, build scripts, automated test suites, data;
- Is traced to several locations in the system, implying ripple effects of impact of change;
- Has a quantifiable effect on system attributes of interest to developers, such as increasing number of defects, negative change in maintainability and code quality indicators.
And last, but not least, thanks a lot to our colleagues from Brazil (Graziela Tonin, Fabio Queda Bueno da Silva, Alfredo Goldman, Guilherme Horta Travassos) for treating us all to such a fun, cultural classic from their part of the world. In case next week you would like to try this yourselves here is the recipe:
Ingredients: Half a lime cut into 4 wedges, 2 Teaspoons brown sugar, 1 2/3 oz Cachaça
Preparation: Place lime and sugar into old fashioned glass and muddle (mash the two ingredients together using a muddler or a wooden spoon). Fill the glass with crushed ice and add the Cachaça.