1. Recovering Design Technical Debt from Source Code Comments Department of Computer Science and Software Engineering Concordia University Montreal, Canada 1 Everton da S. Maldonado e_silvam@encs.concordia.ca Emad Shihab emad.shihab@concordia.ca Nikolaos Tsantalis nikolaos.tsantalis@cse.concordia.ca

2. Research Goal 2 Taking shortcuts to achieve project goals will increase its maintenance cost. This is know as Technical Debt. Our goal is to extract comment patterns that effectively identify Design Debt, one of the most impacting type of Technical Debt.

3. Current solutions 3 SolutionLimitation Tools and techniques to detect bad code smells Design technical debt is more than just Bad Smells Using comments to detect Self-Admitted Technical Debt The approach is too general not addressing Design Debt in detail

4. 4 Research Overview

5. Case study on ten open source projects 5 ProjectReleaseLOCClassesComments Contributors Ant1.7.0115,88 1 1,47521,58770 Jmeter2.3281,3071,18120,08432 Argo UML0.34176,83 6 2,60967,71687 Columba1.4100,20 0 1,71133,8959 EMF2.4.1228,19 1 1,45825,22928 Hibernate3.3.2 GA 173,46 7 1,35611,630216 Jedit4.288,58380016,99155 Jfreechart1.0.19132,29 6 1,06523,12318 Jruby1.4.0150,06 0 1,48611,149291 Squirrel3.0.3215,23 4 3,10827,47440

6. Examples indicating Design Debt 6 Comments: This can lead to code smell, meh! Do we care This is an absurdly long method! Break it up. there should be an interface, instead of the AbstractMessageFolder rethink where exactly some of the following methods belong Cyclic dependency with PersistenceManager hack to view title update replace with listener pattern What does the magic number 6000 represent here? Put it in an explanatory literal! Downcast to avoid using an interface? Yuck. unhappy about this being public... is there a better way? remove use of instance of! design flaw, it doesn't update properly

7. Research question 7 -What comment patterns indicate Self- Admitted design technical debt? How are these comment patterns different than previously proposed comment patterns? We found 176 patterns.

8. How patterns from both approaches are different ? 8 General TD patterns sample This is uncool Risk of this blowing up Remove this code Something’s gone wrong Certainly buggy Treat this as a soft error Probably a bug This isn’t very solid Is this line really safe Something serious is wrong VS Design TD patterns sample ‘%hack%’ ‘%todo%remove%’ ‘%not %sure %’ ‘%why%not%’ ‘%should%instead%’ ‘%todo%dependenc%’ ‘%better%way%’ ‘%ugly%’ ‘%todo%public%’ ‘%for%some%reason%’

9. Research question 9 -Can we effectively detect self-admitted design technical debt using the proposed comment patterns? How does the effectiveness of our approach compare to prior approaches? Our overall precision and recall was of 84.93% and 19.01%. While the prior approach achieved 34.52% and 12.00% precision and recall overall respectively.

10. Approach performance 10 Project Precision % Recall % Apache Ant96.3083.87 Jmeter88.0027.16 Jfreechart83.3310.87 Columba74.07- EMF85.18- Hibernate87.18- Jedit81.92- Jruby88.07- Squirrel Sql88.57- Argo UML88.05-

11. Comparison between approaches 11 There is little overlap between both approaches. Our approach identifies more Design Technical Debt. ProjectsNumber of classes Number of God classes Self-Admitted Design TD classes Overlap between approaches All projects16,24918065311

12. Can automated refactoring mitigate Design Technical Debt? 12 We found that 24.58% of all files containing Self- Admitted design technical debt had at least one refactoring opportunity. Found refactoring opportunities: 90 “extract long method” 147 “move method”