In this presentation André Agostinho e Cassio Silva covers the importance in dealing with technical debt in software engineering showing the real impacts, daily approaches and best practices for mitigations

1. How to justify technical debt
mitigations in Software Engineering
4ª edição | 19 AGO 22
Cássio Henrique
André Agostinho

2. Agenda
What will you learn today
⬡ Definition
⬡ Real Impacts
⬡ Daily approaches
⬡ How to deal with it?
⬡ CoteiBem Case Study
⬡ Conclusion

3. Cost of poor quality software in USA - 2018
2018, CISQ report

4. Cost of poor quality software in USA - 2018

5. The Software Quality Iceberg

6. Swebok v3.0
https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf

7. Definition

8. What is technical debt?
Ward cunningham
The technical debt metaphor treats the cruft as a debt,
whose interest payments are the extra effort these changes require

9. What is technical debt?
⬡ It is the gap between the current state of the product and the ideal
state to continue responding to the business.
⬡ We can measure a "technical debt" by the effort required to fill this gap.

10. How do we get a technical debt?
In many ways, but the most common are:
⬡ To deliver value to the business very quickly,
we ended up going into debt.
⬡ Looking only for the business and
forgetting the technology.
⬡ Wrong decisions.
⬡ And many others ways.

11. Is technical debt from the devil?
⬡ Definitely not, in life we go into debt
to buy expensive things like a house
and car, so we don't spend years
saving money.
⬡ With software it's the same thing, we
are indebted to deliver fast (and the
boss is happy 😁).

12. Why should we pay?
Reference: Elemar JR.
⬡ All debt the longer we take to pay,
the more interest increases
⬡ Deliveries are getting slower and more
expensive
⬡ Many bugs
⬡ People are getting discouraged
⬡ Product walks to death.

13. Real Impacts

14. Real impacts
Survey with 200+
engineers and
engineering leaders
⬡ 52% of engineers believe that technical debt negatively
impacts their team’s morale.
⬡ Over 60% of engineers think that tech debt causes bugs,
outages, and slows down the development process.
⬡ The average engineer spends seven hours per week
dealing with technical debt.
⬡ The majority of engineers (66%) believe the team would
ship up to 100% faster if they had a process for technical
debt.
⬡ 58% of companies still have no process for managing
technical debt.

15. Why does technical debt impact engineering team morale?

16. Engineers spend seven hours per week on technical debt
Measuring Program Comprehension: A Large-Scale Field Study
with Professionals - July 2017 - IEEE
58% of developer time is spent
on code comprehension
Reading code is harder than writing code
⬡ 7 projects
⬡ 78 professional developers
⬡ 3,148 working hours

17. Engineers spend seven hours per week on technical debt
A high amount of technical debt often
means
The time lost fixing this problem is often
invisible to non-technical stakeholders
⬡ More code you need to read
⬡ Code is more difficult to understand

18. Sometimes mess is also necessary

19. Companies could ship up to 100% faster if they had tech debt
under control
Fix the right amount of technical
debt at the right time
⬡ Controlling technical debt is a
prerequisite to delivering value
regularly
⬡ The goal isn’t to have zero mess
⬡ The goal is to get rid of the mess
that slows you down

20. Companies could ship up to 100% faster if they had tech debt
under control
Is it cold? Is it delicious?
It took to long?
Is it right?

21. Daily approaches

22. Communications gaps
⬡ Mitigate the communications
gaps between technical and
non-technical people
⬡ Conflicts it’s normal!
Deal with them!

23. Communications gaps - Example 1
Hi Melissa, the customer approved
the budget for the new feature. The
tech team will share de code repo
and let’s start it!
Nice!! Let’s do it!

24. Communications gaps - Example 1
Git clone ssh:
Git pull origin …
Let me see…
Wow,this module is really bad!
It's going to be very hard to
make any changes to it

25. Communications gaps - Example 1
Lindolfo, I think we should take
some time to refactor this module
before of all. It's a mess!
Houston, we have a
problem here!
Here it comes…

26. Communications gaps - Example 1
Melissa is very
smart! She knows
about it.
Ok Melissa, go ahead!

27. Communications gaps - Example 2
Hi Melissa, the customer approved
the budget for the new feature. The
tech team will share de code repo
and let’s start it!
Nice!! Let’s do it!

28. Communications gaps - Example 2
Git clone ssh:
Git pull origin …
Let me see…
Wow,this module is really bad!
It's going to be very hard to
make any changes to it

29. Communications gaps - Example 2
Lindolfo, I think we should take
some time to refactor this module
before of all. It's a mess!
Those developers always try
to make their code perfect. I
need some evidence that this
is worth it.

30. Communications gaps - Example 2
What is the ROI of this refactoring?
ROI ..what? …..
Let’s stick with implementing only
Important features!

31. Communications gaps - Example 1 x 2
Example 1 Example 2

32. How to deal with it?

33. The pros and cons of dealing with maintenance work
continuously
⬡ Dealing with technical debt continuously
is crucial for most companies, but
especially for those who have achieved
market-fit and aim to deliver quality
products to their customers.
⬡ It’s not always easy to achieve, and
there are both positive and negative sides
to this approach.

34. Agile way of working
⬡ Continuous maintenance work is a
prerequisite to deliver value
regularly.
⬡ Technical debt that requires a
separate project to get back
under control means you won’t
be able to deliver value regularly.

35. Increased developer happiness
⬡ Nobody likes working in a mess,
and a project to deal with
technical debt means there is a
visible mess that people had to
deal with for quite some time.

36. Higher business value through
improved time-to-market of new features
⬡ Technical debt slows you down
⬡ The true cost isn’t in the
developer hours you lose
Cost of delay in putting a new feature
in the market

37. Higher business value through
improved time-to-market of new features
⬡ The cost of that feature being
delayed can be many orders of
magnitude larger than the loss of
developer productivity.
⬡ That’s the true cost of technical
debt, not all those hours.
https://pt.slideshare.net/AndreRocha1/lead-time-and-cycle-time-what-matters

38. You don’t need to ask permission
Always leave the code
better than you found it
⬡ If you play boyscout and you clean up
the code, you need to change to
implement a feature as part of
implementing a feature
⬡ You don’t need to ask for a budget
for it. It’s part of the job, you’re the
expert.

39. Baby Steps: It’s actually easier to get started
⬡ Even if you’re not the tech lead, you
can start on your own by keeping
track of little things you want to clean
up and address them as you go (e.g.
rename some variables, extract a
function…)

40. Figure Out What and How Much Technical Debt You Have
⬡ To begin: start with your mission-critical systems.
▫ What technical debt do they have?
⬡ Take a look at the wider ecosystem
▫ Better put, what technical debt between your
systems is causing expense?
⬡ Get your top ten ideas and put them into a 2x2 matrix:
▫ Easy/hard to pay down on one axis and degree of
benefits on the other. Hopefully the visual will help
you figure out where to start.

41. Decide what to do
⬡ Small/Low interesting
It may ultimately be best to do nothing. For debt that
is either assessed to be “small” or with a “low interest
rate,” it may be optimal to just leave it
⬡ Medium/High Interesting + Low/Medium effort:
Paying back or reducing technical debt will involve
replacing systems and taking the cost hit. This can
either be done immediately with a smart strategy.
▫ Eg: update framework version, cloud reorg and
others quick wins.
⬡ Medium/High Interesting + High effort:
May costs more to solve > Refinance the technical
debt. (Division/labor /Outsourcing)

42. Visible Goals and KPIs
⬡ Define a clear and visible goal for tech debt mitigation
▫ Small chunks / per sprint
▫ Big chunks / per quarter
⬡ Combine quantitative and qualitative OKRs
▫ To Be/Start with/Stop doing it
▫ E.g: Reduce 30% of CI execution time, remove 100%
of useless methods
⬡ Create visible KPIs for team members
▫ E.g: Cyclomatic complexity per 10000 lines of code
▫ E.g: Notify new framework updates on Slack
▫ Support tools and SaaS

43. Big Bang projects
⬡ It’s harder to address big pieces of
technical debt that has accumulated
over time
⬡ Once the team is experienced enough,
they’ll figure out a way to split the work
in smaller chunks.
⬡ This can generally be done continuously
too, although it requires having a clear
vision on the end goal—which is easier
to do with a project for most teams.

44. Not adequately reward
⬡ It’s extremely easy to let normal business
pressures disrupt continuous
maintenance work If engineers don’t get
rewarded for improving the codebase
⬡ They won’t prioritise these properly.

45. Continuous work is invisible and won’t bring praise
Many companies celebrate firefighters
instead of fire-preventers
Continuous work goes unnoticed!
⬡ How many times has an employee been praised
for working extra-hours to solve some production
issue?
⬡ How many times has an employee been praised
for preventing issues from happening in the first
place?

46. CoteiBem: Case study

47. Before dealing with the technical debt, we thought
⬡ CoteiBem is multiplataform.
⬡ CoteiBem is stateless.
But that's not true. CoteiBem used old
packaging which limits its power.
luckily we solved the problem by dealing
with technical debt.

48. Higher efficiency at lower cost (before)

49. Higher efficiency at lower cost (after)

50. Save money
28% Reduction

51. Conclusion

52. Conclusion
⬡ There is no silver bullet for that
⬡ Solve gap communications
⬡ Control technical debt is a prerequisite
⬡ Focus on medium/high interesting
debts and with less effort as possible
⬡ Keep visible all debt fights that you won
⬡ Reward people is important
⬡ Make your kitchen a wonderful place
⬡ Cook with the best cooks

53. Obrigado!

54. References
⬡ Measuring Program Comprehension: A Large-Scale Field Study with Professionals July
2017 - IEEE Transactions on Software Engineering
https://www.researchgate.net/publication/318811113_Measuring_Program_Comprehe
nsion_A_Large-Scale_Field_Study_with_Professionals
⬡ Technical Debt Isn't Technical: What Companies Can Do to Reduce Technical Debt
https://www.infoq.com/articles/reduce-technical-debt/
⬡ Lead time and cycle time. What matters? #SnetTalks1
https://pt.slideshare.net/AndreRocha1/lead-time-and-cycle-time-what-matters
⬡ O que são e “Dívidas Técnicas”? Por que aceitar? Por que pagar?
https://elemarjr.com/arquivo/o-que-sao-e-dividas-tecnicas-por-que-aceitar-por-que-pa
gar/
⬡ https://martinfowler.com/bliki/TechnicalDebt.html#:~:text=Technical%20Debt%20is%2
0a%20metaphor,interest%20paid%20on%20the%20debt.