DevSecCon Boston 2018: Technical debt - why I love it by Mike Bursell
2 likes107 views
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.
More Related Content
Similar to DevSecCon Boston 2018: Technical debt - why I love it by Mike Bursell (20)
DevSecCon Boston 2018: Technical debt - why I love it by Mike Bursell
- 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
- 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 ( [email protected] ) 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.
- 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