This document discusses technical debt and code quality. It explains that software engineers spend most of their time reading code rather than writing it, and identifies factors that slow this down such as bad code structure, duplication, lack of architecture and lack of tests. These problems can be addressed through techniques like automated testing, test-driven development, and tools to analyze code quality. Recognizing where technical debt exists is the first step to improving code and paying it down.

1. Technical Debt
and Qode Cuality
Vlad Korolev
vlad@v-lad.org

2. Quality
2 / 41

3. 3 / 41

4. 4 / 41

5. 5 / 41

6. Quality : Further reading
6 / 41

7. 7 / 41

8. 8 / 41

9. Things to google and people to follow
People
Dr. Deming
Eliyahu Goldratt
Practices
TQM
Kaizen
9 / 41

10. Code Quality
10 / 41

11. 11 / 41

12. 12 / 41

13. 13 / 41

14. 14 / 41

15. Technical Debt
15 / 41

16. 0 10 20 30 40 50 60
0
10
20
30
40
Project Age (Months)
Daystoimplementafeature
16 / 41

17. Why?
17 / 41

18. What does software engineer
mostly do while at work?
18 / 41

19. Write code?
19 / 41

20. Not really
20 / 41

21. Tidelift survey1
1
https://bit.ly/2XDexFO
21 / 41

22. Quora question2
2
https://bit.ly/2ZIZUDt
22 / 41

23. Quora question3
Typical answer
80-90 % reading
20-10 % writing
3
https://bit.ly/2ZIZUDt
23 / 41

24. Robert Martin (Uncle Bob)4
4
https://bit.ly/3c4BPtb
24 / 41

25. Amdahl’s Law
S =
1
(1 − p) + p
s
Where:
p - portion of whole to speed up
s - speed up factor
25 / 41

26. Amdahl’s Law
S =
1
(1 − p) + p
s
Where:
p - portion of whole to speed up
s - speed up factor
Optimistic assumption 80% reading
20% writing
Speed up factor of 2
Double the speed to write code →
10% overall improvement
Double the speed to read code →
60% overall improvement
26 / 41

27. So, how do we speed it up?
27 / 41

28. What’s slows us down?
Bad code structure
Copy-pasta
Lack of architecture
Lack of common style
Lack of unit tests (integration, end-to-end)
28 / 41

29. Bad structure : Spaghetti Code
29 / 41

30. Bad structure : Ravioli Code
100s or 1000s of classes
No cohesion
Each code change affects
30-40 classes
Did we break anything by
the change?
30 / 41

31. Bad structure : Lasagna Code
A lot of layers
Hard to comprehend what happens
where
Hard to understand impact of the
change
31 / 41

32. Copy Pasta
Need new method similar to
existing one
NO PROBLEMO!
Copy paste existing method
Rename and modify
32 / 41

33. Lack of architecture
Let’s just write code
Planning slows things down
We need to get things out fast
This prototype is good enough to ship
33 / 41

34. Lack of common style
Even problem for projects of one
Mental switch delay looking at different parts
Huge restyling change sets for code reviews
Hard to compare history (git bisect)
34 / 41

35. Lack of tests
Unit, Integration, E2E
No safety net
Anxiety and resistance to change
Not clear which parts affected by change
35 / 41

36. OK
36 / 41

37. We Got it
37 / 41

38. What can we do?
38 / 41

39. Recognize the problem
Reckless Prudent
Deliberate We don’t have time for
design
We must ship now and
deal with consequences
later
Inadvertent What’s layering? Now we know how we
should’ve done it
From Robert Martin (Uncle Bob) technical debt quadrant5
5
https://bit.ly/2XDS2QZ
39 / 41

40. Techniques to use
Automated Testing
Unit
Integration
E2E
TDD
Pay down the debt
Throw away your prototypes
40 / 41

41. Tools to help
Py McCabe6
PyLint7
SonarQube8
6
https://bit.ly/3exl5g6
7
https://pypi.org/project/pylint/
8
https://bit.ly/2M707Iq
41 / 41