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


> Principal


> Principal

> You haven’t necessarily created the debt


> Principal


> You don’t have to pay back all the time


> Principal


> 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)


> Domain Model: 2 classes w/ 200+ attributes


> Domain Model: 2 Klassen mit 200+ Attributen

> Hardware only available on eBay


> Domain Model: 2 classes w/ 200+ Attributes


> No new features for more than 10 month


> Domain Model: 2 Klassen mit 200+ Attributen


> 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

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


Sprint

Backlog of Storiesand Bugs


Sprint

Backlog of Stories ,Bugs Technical Tasks,


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


Sprint


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


> Measurable base line and target> Concrete business need> Analyse the Value Chain (it’s usually broken

somewhere)



somewhere)> Fix those places with a prototype



somewhere)> Fix those places with a prototype> Scale


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


> Debt repayment

> Debt conversion


> 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


> You don’t have to pay all of it back

Conclusion



> It has to be managed properly with regards to value, cost and risk

Conclusion



> 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

http://www.martinfowler.com/bliki/StranglerApplication.html

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


> It has to be managed properly

Thanks

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


> 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


> 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


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


What color has your backlog?(stolen from Philippe Kruchten)

Sprint


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



“normal” stories> They have a cost and a value: it is

transparent why they are in the backlog



“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


> 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.



> The value is volatile. The context can change and therefore the value.

> Improvements as part of a new requirement


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.

managing technical debt xpdays latest copy...dealing with technical debt-state of the practice (=...

Documents