The document discusses technical debt in software development. It explains that technical debt is incurred when expedient solutions are chosen that compromise quality and require extra work later. It notes the problems technical debt can cause like slow development, bugs, and employee dissatisfaction. The document recommends making technical debt visible by documenting it, analyzing and prioritizing repayments, and proactively using techniques like code reviews and automated testing to prevent new debt.

1. Why change code
that works?
On Technical Debt & Refactoring
Carsten Windler, 23.01.2020

2. Carsten Windler
Web Developer
Global Head of Software Development
@ HolidayPirates
https://www.linkedin.com/in/cwindler/
https://www.xing.com/profile/Carsten_Windler

3. Meeting with C-Level...

4. "Why is there still technical debt?"

5. On Technical Debt and Refactoring
1. Technical Debt explained
2. Why you want to avoid it
3. How to deal with existing debt
4. Avoid piling up new debt

6. 1. Technical Debt explained

7. Technical debt is a concept
in software development that
reflects the implied cost of
additional rework caused by
choosing an easy or limited
solution now instead of using
a better approach that would
take longer.
tl;dr
https://en.wikipedia.org/wiki/Technical_debt

8. Example: Build a house

9. Photo by Hossein Ghaem on Unsplash

10. Photo by Binjamin Mellish on Pexels

11. Technical Debt
● Work not done properly now
● Has to be done later

12. Why chose the simple solution?
● Time-to-market
● Deadlines
● Ignorance

13. Technical Debt Quadrant (Fowler 2009)
“We don’t have to time for design”
“We must ship now and deal
with consequences”
“What’s layering?”
“Now we know how we
should have done it”
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Reckless Prudent
DeliberateInadvertent

14. Time
QualityCost
DONE
QUICKLY
HIGH
QUALITY
LOW
COST
Cheap
&
Quick
=
Low
Quality
Fast&
Good
=
Expensive
Cheap & High Quality
= Low Priority

15. ● Prototype/POC
● Interim solution
● One single purpose
● Deliver fast
Technical Debt can be ok
Photo by Hossein Ghaem on Unsplash

16. The many forms of Technical Debt
● Bad code quality (e.g. usage of Antipatterns)
● Delayed updates (Framework, Packages, Language…)
● No automated tests
● No/outdated/insufficient documentation
● Issues with infrastructure
● Cumbersome workflows (e.g. no CI/CD)
● Wrong decisions (e.g. chose an abandoned package)

17. 2. Why you want to avoid it

18. Problems with Technical Debt
1. Low development speed
2. Security issues
3. Performance problems
4. Employee satisfaction

19. Low development speed
???
Photo by Bruce Mars on Pexels

20. Technical debt slows down
● Code is hard to understand
● New bugs get introduced easily
● Redundant work necessary (C&P
programming)
● Manual testing needed

21. Security issues
LOL
We got hacked again
Photo by Bruce Mars on Pexels

22. No updates, no security fixes
It’s actually that simple

23. Performance problems
Why is this so slow???
Photo by Christina Morillo on Pexels

24. Performance problems
● Dead code
● Unused assets / 3rd party code
● Missing performance optimisations
● Outdated technologies

25. Web page speed matters
https://blog.hubspot.com/marketing/page-load-time-conversion-rates

26. Employee satisfaction
Why am I even wasting
my time on this?
Photo by Tim Gouw on Pexels

27. Employee satisfaction
● Constant problems & slow development speed
cause frustration
● Many developers get unhappy if they can’t evolve

28. Interest on Technical Debt
Illustration by Carsten Windler

29. Technical Debt is sneaky
Features Architecture
Bugs Technical Debt
Visible Invisible
PositiveValueNegativeValue

30. 3. How to deal with existing debt

31. Make Technical Debt visible!

32. Dealing with Technical Debt
Illustration by Carsten Windler

33. 1. Reveal & Document
● Developers document technical debt (e.g. tickets)
● Properly tagged so it’s easy to find
● Do estimates for value & effort (if possible)
Drawbacks
● Developers are lazy, writing tickets is no fun
● Takes time until this is established
○ Set up regular workshops
○ Constantly chase it

34. 2. Analyze & Prioritize
● Team discusses the tickets
● Final assessment of value/effort
● Prioritization based on value/effort

35. Illustration by Carsten Windler

36. Refactoring != Overengineering

37. Drawbacks
● Additional time needed for team discussions
● Prepare for lengthy discussions

38. 3. Payback
● Debt gets decreased on as prioritized
● Aka Refactoring

39. Code Refactoring is the
process of improving existing
code without changing the
actual behaviour of the
application.

40. In other words:
If we do our job right, nobody will
notice anything!*
* except a performance increase maybe

41. 2 MONTH OF REFACTORING
APP LOOKS EXACTLY LIKE BEFORE
Photo by Negan Scofield on Unsplash

42. Refactoring in Web Development

43. Drawbacks
● Negotiate with stakeholders on
time available for refactoring

44. 4. Avoid piling up new debt

45. Training & Education
● Establish a sense for Code Quality
● E.g. internal workshops
● Conferences for new inspiration
● Online courses, Tutorials
● Code Reviews

46. Guidelines
● Coding Guidelines
○ Code Style
○ Best practices
○ Antipatterns
● Agreed upon by the teams
● The Twelve-Factor App
● Ensure guidelines are met
○ Code Reviews
○ Automated checks

47. Tools
● Static code analysis
○ Linter
○ Code Sniffer
○ Mess detectors / Metrics on Code Quality
■ Complexity, Coupling, Cohesion…
● Run them on pre-commit hook or in the IDE
● Automated security analysis

48. Automated Tests
● Reckless refactoring requires good code coverage

49. Refactor vs. Rewrite

50. "I'll setup a new webservice for this
in 2 days, no problem"*
* dramatization, not a real story

51. One Eternity Later...

52. "It’s done, just a few bugs
to fix and, oh, that one feature
I wasn’t aware of..."

53. Why does that happen?
● Unknown requirements
● Bugs
● Amount of communication underestimated
● Documentation effort
● Automated tests (yikes!)
● Sickness, holidays
● Other important projects
● More unknown requirements

54. #offeatures
time
Replacing an existing application - the plan
Existing application
New application

55. #offeatures
time
Replacing an existing application - reality
Existing application
New application

56. Back to the
Meeting with C-Level

57. “Refactoring is an ongoing progress.
There will always be technical debt.”

58. Thank you!