The document discusses technical debt in software projects. It defines technical debt as compromises made in a project's design or implementation that are known to require future work. These compromises arise due to lack of time, resources, requirements or expertise. The speaker argues that acknowledging technical debt is beneficial because it allows the issues to be documented, addressed through future work, and prevents blame. The document provides recommendations for managing technical debt, such as reserving time for discussion and encouraging honest documentation of compromises made during a project.

1. Technical debt - why I love
it (and so should you)
DevSecCon Boston
Mike Bursell
Chief Security Architect | Red Hat
Sept 2018

2. 2
Agenda
● What is technical debt?
● Bringing technical debt out into the open
● Benefits to projects
● Benefits for stakeholders
● What to do (and not)

3. 3
First: an admission
The two reasons I love technical debt
The bad reason
● There’s lots of it
● It’s interesting
● It keeps me in a job
● I can poke my nose into new projects
The good reason
● When it’s acknowledged, we’re half-way there*

4. 4
First: an admission
The two reasons I love technical debt
The bad reason
● There’s lots of it
● It’s interesting
● It keeps me in a job
● I can poke my nose into new projects
The good reason
● When it’s acknowledged, we’re half-way there*

5. 5
First: an admission
The two reasons I love technical debt
The bad reason
● There’s lots of it
● It’s interesting
● It keeps me in a job
● I can poke my nose into new projects
The good reason
● When it’s acknowledged, we’re half-way there*

6. 6
First: an admission
The two reasons I love technical debt
The bad reason
● There’s lots of it
● It’s interesting
● It keeps me in a job
● I can poke my nose into new projects
The good reason
● When it’s acknowledged, we’re half-way there*
*honestly, we’re not even a quarter-way there, but at least there’s hope

7. What is technical debt?

8. 8
What is technical debt?
And how does it arise?
“Stuff we didn’t do that we should have done”
“Decisions we made that could have been … better”

9. 9
What is technical debt?
And how does it arise?
“Stuff we didn’t do that we should have done”
“Decisions we made that could have been … better”
Examples:
● Neglecting to put authentication on currently non-public APIs
● Lumping capabilities together
● Hard-coding roles to initial expectations without thought to future reqs
● Compiling cipher suite selections into the application

10. 10
What is technical debt?
And how does it arise?
“Stuff we didn’t do that we should have done”
“Decisions we made that could have been … better”
Not always for bad reasons
● Lack of time
● Lack of resources
● Lack of requirements
● Lack of knowledge/expertise

11. 11
Old-style methodologies vs DevOps
(Surely we’re immune now…?)
Yuh-huh.
Old-style (e.g. Waterfall): Product manager makes a decision
● hopefully considered for “next release”
● if enough customers complain, feature might get included
DevOps
● easy to let features slip to the bottom of the board
● unless you consolidate requests, focus on per-sprint features can obscure debt

12. 12
Old-style methodologies vs DevOps
(Surely we’re immune now…?)
Yuh-huh.
Old-style (e.g. Waterfall): Product manager makes a decision
● hopefully considered for “next release”
● if enough customers complain, feature might get included
DevOps
● easy to let features slip to the bottom of the board
● unless you consolidate requests, focus on per-sprint features can obscure debt

13. 13
Old-style methodologies vs DevOps
(Surely we’re immune now…?)
Yuh-huh.
Old-style (e.g. Waterfall): Product manager makes a decision
● hopefully considered for “next release”
● if enough customers complain, feature might get included
DevOps
● easy to let features slip to the bottom of the board
● unless you consolidate requests, focus on per-sprint features can obscure debt

14. Bringing technical debt into the open

15. 15
Bringing technical debt into the open
The importance of naming
Naming allows knowledge
● If technical debt is unacknowledged, it cannot be fixed
● If technical debt is known, decisions can be made
○ Sometimes that decision is, quite rightly, to maintain that debt

16. 16
Bringing technical debt into the open
The importance of naming
Naming allows knowledge
● If technical debt is unacknowledged, it cannot be fixed
● If technical debt is known, decisions can be made
○ Sometimes that decision is, quite rightly, to maintain that debt
For closed source projects, the owner gets to make informed decisions

17. 17
Bringing technical debt into the open
The importance of naming
Naming allows knowledge
● If technical debt is unacknowledged, it cannot be fixed
● If technical debt is known, decisions can be made
○ Sometimes that decision is, quite rightly, to maintain that debt
For closed source projects, the owner gets to make informed decisions
For open source projects, naming is even better
● It allows somebody else to take on the work, if they wish

18. 18
Why is it a security issue?
Because security concerns are often non-functional
● And are therefore less likely to be tracked

19. 19
Why is it a security issue?
Because security concerns are often non-functional
● And are therefore less likely to be tracked
Because of scarcity of knowledge
● Too few owners, architects and designers understand the impact of security

20. 20
Why is it a security issue?
Because security concerns are often non-functional
● And are therefore less likely to be tracked
Because of scarcity of knowledge
● Too few owners, architects and designers understand the impact of security
Because security is often left till last

21. Benefits to projects

22. 22
Benefits to projects
Naming -> documentation
Document why decisions were made
Example: Encryption not included on particular interface.

23. 23
Benefits to projects
Naming -> documentation
Document why decisions were made
Example: Encryption not included on particular interface.
Project documentation
● “We ran out of time, existing reqs don’t include certificate management.”

24. 24
Benefits to projects
Naming -> documentation
Document why decisions were made
Example: Encryption not included on particular interface.
Project documentation
Product documentation
● “This API is designed to be used in a protected environment, and should not be
exposed on the public Internet.”

25. 25
Benefits to projects
Naming -> documentation
Document why decisions were made
Example: Encryption not included on particular interface.
Project documentation
Product documentation
In-line documentation
// 2018-05-02 ( mbursell@redhat.com ) Planned to use TLS 1.2 (check for newer version)
// probably won’t need client authentication. Don’t use ECC cipher suites.
// Certificate management and revocation currently not specced.

26. Benefits for stakeholders

27. 27
Benefits to stakeholders
Documentation -> decisions
Document why decisions were made
Example: Encryption not included on particular interface.
Project documentation
Product documentation
In-line documentation

28. 28
Benefits to stakeholders
Documentation -> decisions
Document why decisions were made
Example: Encryption not included on particular interface.
Project documentation
Product documentation
In-line documentation
Allows reqs to be created
Allows customers to deploy safely
Allows future implementation

29. 29
Benefits to stakeholders
Documentation -> decisions
Document why decisions were made
Example: Encryption not included on particular interface.
Project documentation
Product documentation
In-line documentation
This is now documented, known, and useful technical debt.
Allows reqs to be created
Allows customers to deploy safely
Allows future implementation

30. 30
Technical debt and blame
This is what you’re trying to avoid
Architects
Designers
Engineers
Product managers
Project owners
Sales & marketing
Support
Customers

31. What to do (and not)

32. 32
What to do (and not)
Do:
● Encourage honesty
● Document everything
● Record “I suddenly thought…”
moments
● Reserve time in every project meeting
for discussion of technical debt
● Consider a project “debt recorder”

33. 33
What to do (and not)
Do:
● Encourage honesty
● Document everything
● Record “I suddenly thought…”
moments
● Reserve time in every project meeting
for discussion of technical debt
● Consider a project “debt recorder”
Don’t:
● Allow a culture of blame, even after the
fact
● Assume that it’s better to hide from the
customer
● Put off unit tests just because it’s not
implemented yet

34. 34
What to do (and not)
Do:
● Encourage honesty
● Document everything
● Record “I suddenly thought…”
moments
● Reserve time in every project meeting
for discussion of technical debt
● Consider a project “debt recorder”
Don’t:
● Allow a culture of blame, even after the
fact
● Assume that it’s better to hide from the
customer
● Put off unit tests just because it’s not
implemented yet
Properly documented and
managed debt is a project
asset

35. Mike Bursell
Chief Security Architect | Red Hat
Blog: https://aliceevebob.com

36. THANK YOU
plus.google.com/+RedHat
linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHat