Managing Technical Debt XPDays latest copy...Dealing with Technical Debt-State of the Practice (=...
Transcript of Managing Technical Debt XPDays latest copy...Dealing with Technical Debt-State of the Practice (=...
Lean Principles and the Management of
Technical Debt
Sven Johann, November 2016
Definition
What is Technical Debt?
3
A design or construction approach that's beneficial in the short term
but that creates a technical context in which the same work
will cost more to do later than it would cost to do now
(including increased cost over time)(Steve McConnell)
The Metaphor> Interest
The Metaphor> Interest
> Principal
The Metaphor> Interest
> Principal
> You haven’t necessarily created the debt
The Metaphor> Interest
> Principal
> You haven’t necessarily created the debt
> You don’t have to pay back all the time
The Metaphor> Interest
> Principal
> You haven’t necessarily created the debt
> You don’t have to pay back all the time
> Debt value is very volatile (Call Option)
Debt is not a bad thing, it’s a Strategy
Some Examples > 50% of the code in one class (> 50 KLoC)
Some Examples > 50% of the code in one class (> 50 KLoC)
> Domain Model: 2 classes w/ 200+ attributes
Some Examples > 50% of the code in one class (> 50 KLoC)
> Domain Model: 2 Klassen mit 200+ Attributen
> Hardware only available on eBay
Some Examples > 50% of the code in one class (> 50 KLoC)
> Domain Model: 2 classes w/ 200+ Attributes
> Hardware only available on eBay
> No new features for more than 10 month
Some Examples > 50% of the code in one class (> 50 KLoC)
> Domain Model: 2 Klassen mit 200+ Attributen
> Hardware only available on eBay
> No new features for more than 10 month
> Retirement / resignation of a developer is a thread to the business
SPIEGEL ONLINE zur Lage der CoBa::
“Auch ihre schlechte und veraltete IT machte der Bank in den vergangenen Jahren zu schaffen.”
Understanding the Landscape
https://insights.sei.cmu.edu/sei_blog/2016/08/the-future-of-managing-technical-debt.html
Technical Debt in your Sprint
What color has your backlog?(reused from Philippe Kruchten)
Sprint
Backlog of Stories
What color has your backlog?(reused from Philippe Kruchten)
Sprint
Backlog of Storiesand Bugs
What color has your backlog?(reused from Philippe Kruchten)
Sprint
Backlog of Stories ,Bugs Technical Tasks,
What color has your backlog?(reused from Philippe Kruchten)
Sprint
Backlog of Stories ,Bugs
and
Technical Tasks,
Technical Debt
Dealing with Technical Debt-
State of the Practice
Dealing with Technical Debt-
State of the Practice(= not good)
Better:Managing Technical Debt
What color has your backlog?(reused from Philippe Kruchten)
Sprint
Backlog of Stories ,Bugs
and
Technical Tasks,
Technical Debt
Visible Invisible
Positive value
Negative value
(Reused from Philippe Kruchten)
Colors in a Product
Lean Principles
Lean PrinciplesObsession: Reduce Waste
• Specifying Value• Identify and create
value streams• Making value flow• Pull production, not
push• Striving for
perfection
• Eliminate waste• Amplify learning• Decide as late as
possible• Deliver as fast as
possible• Empower the team• Build integrity in• See the whole
Lean Software Dev**Lean Manufacturing*
* Womack, Jones: The Machine That Changed The World ** Poppendiecks
High Value Examples(based on Data)
What improvements matter to your Business?
Some Examples > Lead time too long> # of bugs, expensive bugs> Development too expensive> Development too slow> Poor application performance> Dependent from individual developers> Online experiments> Poor usability> (Real-time) analytics> Security & privacy problems
> Measurable base line and target
Lean Approach to those Problems
> Measurable base line and target> Concrete business need
Lean Approach to those Problems
> Measurable base line and target> Concrete business need> Analyse the Value Chain (it’s usually broken
somewhere)
Lean Approach to those Problems
> Measurable base line and target> Concrete business need> Analyse the Value Chain (it’s usually broken
somewhere)> Fix those places with a prototype
Lean Approach to those Problems
> Measurable base line and target> Concrete business need> Analyse the Value Chain (it’s usually broken
somewhere)> Fix those places with a prototype> Scale
Lean Approach to those Problems
Lean PrinciplesObsession: Reduce Waste
• Specifying Value• Identify and create
value streams• Making value flow• Pull production, not
push• Striving for
perfection
• Eliminate waste• Amplify learning• Decide as late as
possible• Deliver as fast as
possible• Empower the team• Build integrity in• See the whole
Lean Software Dev**Lean Manufacturing*
* Womack, Jones: The Machine That Changed The World ** Poppendiecks
• Cost/Benefit-Analysis• It’s always an estimate!• Don’t try to be exact, find “clues”• Use Fermi-Questions
To Pay Or Not To Pay
> Debt repayment
To Pay Or Not To Pay
> Debt repayment
> Debt conversion
To Pay Or Not To Pay
> Debt repayment
> Debt conversion
> Just pay the interest
analyze evaluate
improve
architecture improvement
method
http://aim42.org/
Questions?
Thanks
Conclusion
> There will always be Technical Debt - it’s not a bad thing
Conclusion
> There will always be Technical Debt - it’s not a bad thing
> You don’t have to pay all of it back
Conclusion
> There will always be Technical Debt - it’s not a bad thing
> You don’t have to pay all of it back
> It has to be managed properly with regards to value, cost and risk
Conclusion
> There will always be Technical Debt - it’s not a bad thing
> You don’t have to pay all of it back
> It has to be managed properly with regards to value, cost and risk
> Paying down valuable debt is a first class requirement
Architectural Approaches
Strangler Pattern> Motivated by Strangler Vines in Queensland> Don’t invest too much time in critical rewrites
(= bankruptcy of a system), because it almost always fails
> Instead: “gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled”
> Gradual ROI, less risk than big bang> http://www.martinfowler.com/bliki/
StranglerApplication.html
Strategic Design
> Part of Domain Driven Design
> says that “a system can’t have the same high level of quality throughout the system”
> Exercise: do a risk plane
> You need to measure what is valuable to the user!
How Buildings Learn
How Buildings Learn
> Different artefacts change at different rates> Google puts a lot of effort into shared long-
term infrastructure like GFS> Factor your system so that artefacts that
change at similar rates are together> Examples
> What changes often in your system?> What changes rarely in your system?
Conclusion
> There will always be Technical Debt
> It’s not always bad
> You don’t have to pay all of it back
> It has to be managed properly
Thanks
Lean
Technical Backlog
Risk Plane
Measure
Cleanup release
To Pay or not to Pay
Lean
Technical Backlog
Risk Plane
Measure
Cleanup release
To Pay or not to Pay
Cleanup Release
> Purely technical release to improve the codebase
Cleanup Release
> Purely technical release to improve the codebase
> If you have deadlines where you know that the code is messy afterwards
> Improve only if you know what’s important> Be careful with changing code which does not
really needs to be improved
Cleanup Release
> Purely technical release to improve the codebase
> If you have deadlines where you know that the code is messy afterwards
> Improve only if you know what’s important> Be careful with changing code which does not
really needs to be improved
> Every shortcut is still fresh in your head
Lean
Technical Backlog
Risk Plane
Measure
Cleanup release
To Pay or not to Pay
Lean
Technical Backlog
Risk Plane
Measure
Cleanup release
To Pay or not to Pay
Lean Approach (1/2)
> Talk to the senior executives> What is the most important thing you need
changed with regard to your systems?> Usually they know
Lean Approach (1/2)
> Talk to the senior executives> What is the most important thing you need
changed with regard to your systems?> Usually they know
> Verify those problems> Talk also to key developers> Validate all the assumptions where the time is
spent or where things are slow> Sometimes people have intuitions
Lean Approach (2/2)
> Measure the baseline and set the target, e.g.> save 20% of the cycle time> reduce deployment effort> reduce development time of certain features> increase transaction volume / reliability / etc.
Lean Approach (2/2)
> Measure the baseline and set the target, e.g.> save 20% of the cycle time> reduce deployment effort> reduce development time of certain features> increase transaction volume / reliability / etc.
> Look at the Value-Chain to improve> impacted negatively in one way or the other> critical points where making a difference has a
big impact> innovate at the bottleneck(s) where accelerating
or improving makes a difference
Lean Approach - Discussion
> Good if you have overwhelming problems
> Cost and value are “easy” to measure
> Risk-reduction with prototypes (start small and scale
Lean
Technical Backlog
Risk Plane
Measure
Cleanup release
To Pay or not to Pay
Lean
Technical Backlog
Risk Plane
Measure
Cleanup release
To Pay or not to Pay
Lean
Technical Backlog
Risk Plane
Measure
Cleanup release
To Pay or not to Pay
What color has your backlog?(stolen from Philippe Kruchten)
Sprint
Backlog of Stories ,Bugs
and
Technical Tasks,
Technical Debt
> Debt items can be treated as planned stories
Technical Backlog?(stolen from Philippe Kruchten)
> Debt items can be treated as planned stories> These stories can be small and big as
“normal” stories
Technical Backlog?(stolen from Philippe Kruchten)
> Debt items can be treated as planned stories> These stories can be small and big as
“normal” stories> They have a cost and a value: it is
transparent why they are in the backlog
Technical Backlog?(stolen from Philippe Kruchten)
> Debt items can be treated as planned stories> These stories can be small and big as
“normal” stories> They have a cost and a value: it is
transparent why they are in the backlog> Defining the value is an unsolved problem!
You need a guess, guided by the measurements, risk planes
Technical Backlog?(stolen from Philippe Kruchten)
> It can sometimes be hard for the PO/PM to decide on TD items (prio, benefit) if it is too technical (e.g. new Java Runtime)
What color has your backlog?(stolen from Philippe Kruchten)
> It can sometimes be hard for the PO/PM to decide on TD items (prio, benefit) if it is too technical (e.g. new Java Runtime)
> The value is volatile. The context can change and therefore the value.
What color has your backlog?(stolen from Philippe Kruchten)
> It can sometimes be hard for the PO/PM to decide on TD items (prio, benefit) if it is too technical (e.g. new Java Runtime)
> The value is volatile. The context can change and therefore the value.
> Improvements as part of a new requirement
What color has your backlog?(stolen from Philippe Kruchten)
aim42architecture improvement method
analyze evaluate
improve
architecture improvement
method
http://aim42.org/
How Buildings Learn
> Do you have different change rates?
Microservices / SCS / Replaceable Component Arch.