DevOpsDays Warsaw 2015: Placebo of Progress – Caoimhin Graham
•Als PPTX, PDF herunterladen•
0 gefällt mir•224 views
This document discusses technical debt in software development. It defines technical debt as work that needs to be done to properly complete a job or make future changes easier. While some technical debt is inevitable, failing to track and repay it can cause problems over time as debt accumulates interest. The document recommends identifying, qualifying and prioritizing technical debt to manage it sensibly. Factoring debt repayment into costs and using strategies like conversion or interest payments can help control technical debt.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie DevOpsDays Warsaw 2015: Placebo of Progress – Caoimhin Graham
Ähnlich wie DevOpsDays Warsaw 2015: Placebo of Progress – Caoimhin Graham (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
DevOpsDays Warsaw 2015: Placebo of Progress – Caoimhin Graham
- 1. Placebo of Progress Caoimhin Graham (Keeeeeevin Graham)
- 4. Agenda 1. Bio 2. What is technical debt? 3. Is technical debt bad? 4. How to identify and manage technical debt.
- 5. 1. Bio
- 7. > 9 years in industry
- 8. > 3 years building stuff for UK Gov
- 9. > 3 Years
- 10. > 3 Years
- 13. 2. What is technical debt?
- 14. “Technical Debt is a recent metaphor referring to the eventual consequences of any system design, software architecture or software development within a codebase.”
- 15. “The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper.”
- 16. “If debt is not repaid then it will keep accumulating interest making it hard to implement changes later on.”
- 18. Technical debt demands a maturity and balance of decision making
- 19. Reckless Prudent Deliberate Inadvertent “We don’t have time for design” “We must ship now and deal with the consequences” “Whats Layering?” “Now we know how we should have done it”
- 20. What causes technical debt?
- 21. Me
- 22. You
- 23. Because $reasons
- 24. The technical debt taste test…
- 25. Knowningly implementing a single point of failure
- 26. Lack of password hashing
- 27. Bad code == Bad Code
- 28. 3. Is technical debt bad?
- 30. No……but not paying your debt is!
- 31. Ignorance of or failing to track technical debt is bad
- 32. To ignore technical debt is to build a house on a cliffs edge without ever inspecting the cliff or the threat it poses to your house. You just keep adding more bricks
- 33. And because the internet is awesome…
- 35. The impact of technical debt can be slow to grow and can eventually spiral out of control…
- 37. Moral of the story (and talk)…
- 38. Establish good habits and technical debt can enable, establish bad habits and technical debt can disable
- 40. 4. How to identify and manage technical debt.
- 41. Knowing your exposure to technical debt is key to sensibly tackling it
- 42. Identify, qualify and prioritise your debt
- 43. Identify
- 44. Qualify
- 45. Prioritise
- 46. Good debt == New Bad debt == Old
- 47. $$ Paying it back $$
- 48. Factor technical debt into your cost of development.
- 49. 1. Debt repayment 2. Debt conversion 3. Interest only payments
Hinweis der Redaktion
- Talk isn’t going to be that technical Counselling session about technical debt and how we can use it for empowerment
- make (someone) less angry or hostile.
- I’m from the city that built the titanic; quite possibly one of the most famous placebo effects in history Why would you provide enough lifeboats on the unsinkable ship? You’ll ruin the view from the cabins!
- Opinions are my own My accent is strange
- Joined as a placement engineer
- Digital transformation
- 12 million people registered
- Billions in European subsidy money
- Technical debt to me is the effect of tactical decision making in a strategic scenario Short term vs long term
- You will always strive to complete the work, probably in an incremental method
- Technical debt has a cost that is ever increasing if ignored
- Imagine a game of jenga where you start with no blocks and you keep get 3 new blocks every minute. You have to place 3 along the bottom and then you have to build the tower as high as it can go. You soon realise you need to balance the placement of blocks at the top (new functionality) and throughout the stack for stability. Failure to strike this balance would lead to the tower collapsing - Jenga
- http://martinfowler.com/bliki/TechnicalDebtQuadrant.html Reckless/Inadvertent – Jumping on the bandwagon and using docker without due diligence Prudent/Inadvertent - Designing and implementing a solution according to best practice/research only to find it completely inappropriate to your use-case e.g. deploying a textbook MongoDB cluster only to realise that as a transactional system there are some hidden problems.
- Ignorance Money Market oppertunity Planning deadlines Lack of upfront design Poor working practices Lack of responsibility for the solution
- No compromises with security; thinking shoud always be long-term
- Domains and cookies
- Rapid delivery/prototyping Getting early feedback on features Proving theories before widespread adoption e.g. will it work
- The result of technical debt is that: People complain about slow delivery, increased numbers of defects, poor performance This increases pressure to take more short-cuts to fix the problems which increases the debt This normally excasterbautes the original problems More short-cuts…
- Moral of the story
- Moral of the story
- Criminology theory that says that maintaining and monitoring urban environments to prevent small crimes such as vandalism, public drinking, and toll-jumping helps to create an atmosphere of order and lawfulness, thereby preventing more serious crimes from happening. Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside. Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars. https://en.wikipedia.org/wiki/Broken_windows_theory
- Benefits Risk Cost
- Technical debt smells Monitor all the things and analyse trends over time Slowing velocity for a team Nightmare releases Old versions of packages in use (stagnated code) Numbers of defects and their accumulation rate (trend analysis) Low automated test coverage Number/quantify of failed CI builds Code/component coupling Maintenance effort
- Track it somewhere Keep it simple initially and use something that works for you A brief description Rough estimation of effort/story points to address Probability the code will be used in future changes (to assess impact)
- Once you have qualified your debt you will have a good idea of the priorty
- Benefits Risk Cost
- Repayment == refactoring Conversion == something better but not perfect (incremental) Interest only == accept and live with the existing debt