Download to read offline
Uploaded byLivatek
Technical debt as asset
The document discusses technical debt in software development. It defines technical debt as shortcuts taken due to ambitious deadlines and lack of resources that reduce code quality. This leads to increased costs of maintenance and changes over time. The document recommends avoiding technical debt by using modular architectures, test-driven development, and shared coding standards. It suggests either refactoring code incrementally over time or deliberately taking on small, documented amounts of debt for bursts of new features before cleaning up. Technical debt can also be accepted but the interest costs must be managed.
More Related Content
Similar to Technical debt as asset
![Technical debt in cyber ark [agile practitioners-2015]](https://cdn.slidesharecdn.com/ss_thumbnails/technicaldebtincyberarkagile-practitioners-2015-150201082255-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
![Lect 1 Number systems and base conversions. [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/lect1numbersystemsandbaseconversions-260111134109-67c2d865-thumbnail.jpg?width=640&height=640&fit=bounds)
Technical debt as asset
- 1. Using technical debtas an asset Giving the market what it wants now without losing your pants later Jesper Lindholt, Livatek – jlin@livatek.com
- 2.
- 3. Technical debt • Whatis it and where is it from? • How to avoid it • Fixing it when you got it • Using it as an asset (!) source: www.defenselink.mil
- 4. Doing the rightthing Business point-of-view Doing the thing right Tech point-of-view • What the market wants • What we promised our users • What we promised our investors • What will bring fantastic value to our clients • Right architecture • Test coverage • Modular • Documentation
- 5. Where do thingsgo wrong? Too much ambition • Features • Product roll-outs • Dead-lines without enough resources • Time • Budget • Skills • Tools leads to technical debt • Corners cut • Low quality work "Wet shorts" by philosophygeek
- 6. Increased cost of change Increased softwarerisk Who wants to work with stale and stinky code? Increased organizational risk (incl. chief scientist) Cowboy code that is harder to maintain and change Lack of architecture (beware creeping bug) DEBT INTEREST % Doing the thing wrong
- 7. Technical debt =>Cost of change Cost of change Time Simple, test-driven designs Rapid coding without testing
- 8. Avoiding technical debt Simple! Dothe Thing Right!
- 9. Levers and handles Languages, toolsand infrastructure Process, culture and habits Development discipline Software architecture
- 10. Levers and handles Languages, toolsand infrastructure Process, culture and habits Development discipline Software architecture • Choosing right language • Shared infrastructure • Style checking tools • Code conventions • Demand unit-test coverage • Strong definition of “Done” • Service Oriented Architecture • Modularity • Agree to having a process • Team operating agreement • Learning culture • Test-driven development
- 12. BUT - youalways do have a choice Let your customers down Work harder Be deliberate Focus your limited resources in a way that best prepares you for the future Work longer hours Forget test coverage Throw it all out the window Reduce internal quality Reduce accountability Say “no”
- 13.
- 14. QUESTION TO SELF Arewe going to be around longer than short-term? YES
- 15. FUNDAMENTAL Later – youwill grow - your product - your team
- 16. That means thatyou will…. • decide on purpose where to cut corners • document corners cut in your task management system • use systems to support communications and limit confusion NOT, that you will • have no time for architecture • ignore the iron triangle of (function, time, cost) and accept unrealistic dead lines
- 17. We have it….. Dealingwith it
- 18. Dealing with technicaldebt • Replace the whole thing – debt repayment • Incremental refactoring – paying back in installments • Live with it, pay the interest And bear the opportunity cost Gregory F. Maxwell <gmaxwell@gmail.com>
- 19. Technical Debt As anasset
- 20. The exception toprove the rule Cost of change Time Simple, test-driven designs Rapid coding without testing INTERESTING!
- 21. Can we achievethis?? Cost of change Time
- 22. Hacking it • Throwall some rules out the window • Do it in bursts – and then clean up • Obvious advantage • Leap forward for product functionality • Less-obvious advantages • Team bonding • Team gets to find its limits Pay-back time! Forget it, and you’ll be paying interest - and interest of interest Debt
- 23. My own pitch Livatek Teammanager
- 24. Technical debt -summary • Main source: when busy doing the right thing (needed in market) => not enough time/money to do the thing right • Problems: cowboy code, lack of architecture, no test coverage • Issues: cost of maintenance, cost of change, creeping bugs, software risk, organizational risk • Avoid with: modular SOA architecture, shared values in team, unit-test coverage, test-driven development • Accept it: only deliberately and when documenting • Do not just: work harder and longer – but focus • You have it: start all over, refactor module by module, or live with it • As asset: code wildly for a week – and clean up for a week
- 25. Contact Livatek GmbH Hamburg Germany +49 4060946277 de@livatek.com Livatek A/S Aarhus Denmark +45 7734 3090 dk@livatek.com Jesper Lindholt, CEO jlin@livatek.com +380 50 410 8070 +45 3024 8500 @jlindholt / @livatek linkedin.com/in/jesperlindholt
Editor's Notes
- #3 I am Jesper – founder of Livatek We are a Danish company in Ukraine We help our clients in Western Europe tap into a Ukrainian talent pool for software development. We don’t do outsourcing but facilitate distributed teams with higher flexibility and lower costs. Over the years, my team and I have delivered around ½ million development hours.
- #4 What are the symptoms? Where does it come from?
- #5 The road to hell is paved with good intentions. Technical debt exists because of wishes to do the right thing. Why do we want to do the right thing – because it IS the right thing to do. Doing the thing right is something different. And there is sometimes a conflict.
- #9 But that takes: money, resources, time, skills – whatever it is that we do not have enough of
- #11 Looking at the big picture, the overheads of implementing each of these are not great. Developer objections are often of the running next to the bicycle type. We are so busy that we don’t have time to get on the bicycle.
- #16 Keep in the back of your head that you are going to scale your product and your team