Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Technical debt

For developers... and managers!

November 2015
Luis García Castro

Who am I

Recurring comments

Without words
  • Didn't we document this services?
  • I thought we'd tested this module...
  • Fixing this will break that ...I think
  • Don't touch that, last time someone touched $whatever broke
  • Write a comment and we'll fix it later
  • Write a TODO so it'll be fixed later
  • Write a comment there, just above the TODO
  • I just changed ONE line!

Didn't we document
this services?

  • Didn't we document this services?
  • I thought we'd tested this module...
  • Fixing this will break that ...I think
  • Don't touch that, last time someone touched $whatever broke
  • Write a comment and we'll fix it later
  • Write a TODO so it'll be fixed later
  • Write a comment there, just above the TODO
  • I just changed ONE line!

I thought we had tested
this module...

  • Didn't we document this services?
  • I thought we'd tested this module...
  • Fixing this will break that ...I think
  • Don't touch that, last time someone touched $whatever broke
  • Write a comment and we'll fix it later
  • Write a TODO so it'll be fixed later
  • Write a comment there, just above the TODO
  • I just changed ONE line!

Fixing this will break that
...I think

  • Didn't we document this services?
  • I thought we'd tested this module...
  • Fixing this will break that ...I think
  • Don't touch that, last time someone touched $whatever broke
  • Write a comment and we'll fix it later
  • Write a TODO so it'll be fixed later
  • Write a comment there, just above the TODO
  • I just changed ONE line!

Don't touch that!
last time someone touched $whatever broke

  • Didn't we document this services?
  • I thought we'd tested this module...
  • Fixing this will break that ...I think
  • Don't touch that, last time someone touched $whatever broke
  • Write a comment and we'll fix it later
  • Write a TODO so it'll be fixed later
  • Write a comment there, just above the TODO
  • I just changed ONE line!

Write a comment and
we'll fix it later

  • Didn't we document this services?
  • I thought we'd tested this module...
  • Fixing this will break that ...I think
  • Don't touch that, last time someone touched $whatever broke
  • Write a comment and we'll fix it later
  • Write a TODO so it'll be fixed later
  • Write a comment there, just above the TODO
  • I just changed ONE line!

OMG!
I just changed ONE line!

  • Didn't we document this services?
  • I thought we'd tested this module...
  • Fixing this will break that... I think
  • Don't touch that, last time someone touched $whatever broke
  • Write a comment and we'll fix it later
  • Write a TODO so it'll be fixed later
  • Write a comment there, just above the TODO
  • I just changed ONE line!
My reasons to give this talk
  • Some guidance to technical staff about how business decissions are made
  • Some guidance to business staff about how technical decissions are made
  • Help to manage technical debt in a more explicit and transparent manner
  • Raise awareness on this issue

Content

  1. Introduction to technical debt
    • Analogies with financial debt
    • Types of technical debt
    • Symptoms
    • Advantages and disadvantages
  2. How, when and why borrow
    • Avoiding unitended debt
    • How to borrow intentionally
    • Technical debt vs low quality code
  3. Paying off technical debt
Introduction

«Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. [...] The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.»

Ward Cunningham, March 1992

  • "Ward" Cunningham is an American computer programmer who developed the first wiki.
  • You start writing an application. In the beginning there is no need for user roles. Everyone can do anything. At some point you start having two different permissions for a specific action. The tech team considers whether to create a full fledged permission system, but at this point it really looks like over engineering. Some time later another thing requires the differentiation of users, and then another and another. The solution is refactoring it to have a decent permission system. To make this refactoring will take way more time than just adding another method, but will simplify the code and make future permissions to be added with one line of code, or even by just adding a row in the database.
    • * 4 now (the permission), 22 later (the refactoring, that now is a bit more complicated)
    • * 21 now (the refactoring), 0 later (the permission)
    • * 4 now (the permission), no refactoring at all, and then 5 for the next permissions, and then 6, 7… until the point a new refactoring is suggested, now costing 50-something
Analogies with financial debt
  • Interest

  • Capital pay off

  • Extending a loan

  • Bankruptcy

  • Technical inflation

  • Fiscal amnesty

  1. Interest - Every minute you spend with not very clean code
  2. Capital Pay off - Refactoring
  3. Extending a loan - Design negligencies
  4. Bankruptcy - Situation with an interest over the debt so large that it is impossible to move forward and we need a complete rewrite
  5. Technical Inflation - When the current level of our technology is old enough to lose compatibility with the rest of the industry
  6. Fiscal Amnesty - Discard prototypes, products or components and renounce to use them
Types of technical debt
  • Intended vs NOT intended
  • Design or architecture debt
  • Quality debt
  • Testing debt
  • Knowledge and documentation debt
  • Environmental debt
  • Intended: “No time to do it multi-language, that will be done in the future”
  • Intended: “No time to complete the tests, that will be done when we deploy this in PRO”
  • Not intended: Letting someone to write code that does not follow a certain standard
  • Not intended: An important design decission that ultimately fails
  • Not intended: Left the junior programmer unsupervised
  • Design: non optimal solutions, shortcuts
  • Tests: Not many automatic tests and too many regression testing
  • Documentation: Only a few properly know the system
  • Hardware, environments,... too many manual actions
Symptoms
  • Loss of productivity, motivation, ...

  • Increase in manual testing

  • Repeated delays in deliveries

  • Duplicated code

  • Unreadable code

  • Unstoppable increase in bugs

  • Excessive stress on each delivery

  • Fear to touch the code

  • Outdated libraries

  • ...
  1. Whenever we can, we measure productivity (Scrum)
  2. We spend too much time in regression testing
  3. It is increasingly difficult to meet the deadlines
  4. Leads to anomalies and support problems
  5. Lack of quality and control
  6. The teams suffers too much pressure
  7. 80% of of the time is spent reading code, if not understood can not be built
  8. It's all so delicate that there is no way to touch without breaking anything
  9. We are not able to update versions
Advantages and disadvantages
  • Some advantages:

    • It shortens Time To Market
    • It preserves the company capital (essential in startups)
    • Certain decisions and costs are postponed
  • And some disadvantages:

    • Reduces speed and productivity
    • Increases the risk
    • Restricts new developments
    • Leads to a vicious circle
  • The mantra created by LinkedIn’s founder Reid Hoffman “if you are not embarrassed by the first version of your product, you’ve launched too late” quickly became an excuse for an anything goes approach. Thousands of startups have launched and failed precisely for the lack of quality.
  • MVP vs MLP

How, when and why



Why not

Exercise: Draw your technical curve (link)

  • Real curve vs desired curve
  • old debt is bad and new debt is good
  • The real curve (chainshaw)
  • Debt baseline and debt ceiling
  • TDD and Scrum help
Avoiding unintended debt
  • Automate tests as much as possible (CI )

  • Share the knowledge (technical and functional)

  • Leave the code cleaner than you found it

  • Settle on a good DoD

  • Aim for Kaizen: TDD, BDD, Fail Fast, Peer Reviews, Code Reviews, ...

  • Limit the WIP. Always!

  • Monitor the debt at every moment

  • And finally: Never ask for permission to do your job properly!

How to borrow intentionally
  • All the inended debt can and should be monitored (by definition)
  • With the same consideration as flaws or bugs
  • Include your debt in the Product Backlog
  • Monitor the speed of the project/teams
  • Monitor the amount of rework
  • Adapt your budgets
  • Measure debt in money

It’s a responsibility of the tech team to make business understand the consequences of this kind of action

Technical debt
vs
Low quality code

  • Technical debt can be paid by refactoring. It takes time but it’s doable. But when code is just bad, refactoring is way, way harder.
  • Michael Feathers, have defined legacy code as code without tests:
    “Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”

Paying off technical debt



Developer

When developers propose a big rewrite, and for whatever crazy reasons, business agrees, the stage is set for a new kind of failure:

  • It turns out that it’s virtually impossible to track all functionality in a legacy code base, and few rewrite projects take the huge necessary time to document everything.
  • Business will ask is about deadlines. Estimating a big rewrite is probably one of the most unrealistic things one can try to do.
  • Business will not accept all new features to be halted. Therefore there will be the need to keep track of them, and to reimplement them as well. And all relevant data should be migrated
  • In the rush to convince business, developers will promise all kinds of things, like that the refactoring will make the system faster, more robust or scalable…
  • Given part of the problem was developer’s inexperience in coding itself, how can they guarantee that now they know better?
  • Generally, planning is not a particular strength of the kind of project that ends up needing a rewrite. Will the rewrite be properly planned?
Before paying the debt...
  • Have we estimated how much it costs paying and not paying?
  • Do we believe the estimates?
  • How will we reduce the current effort to spend it on debt?
  • How much does a dirty solution cost?
  • How much does the cleanest solution cost?
  • How much will a clean solution cost if we do the dirty one now?
How to pay off technical debt
  1. Discuss with the technicians in charge your proposal and its scope
  2. Measure with them the debt you want to pay
  3. Clearly communicate the implications to the business managers
  4. Achieve explicit decisions about wheter to pay off more or less debt
  5. Design strategies to avoid generating new debt when paying off
  6. Take explicit decisions about when and how you will pay off

OK, but... is it good or bad?

Without words

The most widespread opinion:

Ron Jeffries thinks it is always BAD:

  • Agile software development is about turning “next time” into “this time”, as often and as frequently as we can. It’s about improving the design as often as we can, as soon as we can.
  • Sooner, or later, it seems, we’ll have an idea or an understanding that we can’t put in, because we, or the software, has moved on. But if we can put off that moment as long as possible, we’ll do better
Bibliography

Ask Me Anything !!

Thank you