search

dwyl / product-owner-guide

:rocket: A rough guide for people working with dwyl as Product Owners
84 stars 14 forks source link

Understanding technical debt #3

Open iteles opened 7 years ago

iteles commented 7 years ago

This is possibly the most foreign concept to product owners; most don't see a reason for it to exist. They also don't see the urgency/need to work on reducing the technical debt systematically rather than letting it continue to pile up (thanks @nelsonic for the link).

It would actually make quite a good blog post! In the meantime, a short explanation should be included in this repo.

nelsonic commented 7 years ago

@iteles good plan. 👍

Cleop commented 6 years ago

What is technical debt? Technical debt is a term to describe the implied cost of rework caused by choosing an easy solution now instead of using a better approach that would take longer in the first instance. It may feel abstract and hard to understand but it is crucially not ignored.

In other words, whilst in agile methodology we often talk about iterative growth and only building what is necessary, this should not mean that corners are cut in the short term that will inevitably end up with greater costs of time and resources later down the line.

If technical debt does accrue it is worth reducing it systematically. If left untouched, as other development continues, the debt will grow as the new work added will also need reworking when the debt is finally addressed. Just like financial debt grows because of interest.

@iteles @nelsonic - what do you think of this definition for now? I'm finding it a tricky one to deliver clearly so please chime in with any rewording/ suggestions.

iteles commented 6 years ago

@Cleop This is very clearly put, but I would alter the tone a little.

Technical debt (in my humble view) is not inherently a bad thing or a result of ineptitude or laziness. It should be a result of a measured decision to create something that yields validated learning sooner, with an equally calculated decision that it should be paid back in the near future.

It might also be worth adding a note here that this is related but different to the fact that changing requirements/direction and increased knowledge of the project throughout its lifetime require a team to factor in time to go back and adapt older code to be more performant/relevant/consistent.

nelsonic commented 6 years ago

@Cleop technical debt is the result of taking shortcuts / cutting corners to meet (unrealistic) deadlines instead of clearly communicating why quality is essential.

@iteles, with respect, I could not disagree more. From experience of having to fix/maintain work with Technical Debt it is soul destroying. It is inherently (and always) bad like processed/refined sugar or "Reality" TV. image image

The people who don't understand Technical Debt should not be working in Software Development. Or, they should all be working for the "competition"; where relaxed attitudes to quality are "ok".

Technical Debt always costs way more time, effort and morale than doing it right the first time.

If it's possible to build it "right" the first time, why do it any other way?

nelsonic commented 6 years ago

Technical Debt is very much like Credit Card debt.

image It can seem "OK" in the short run and if you pay it off fast enough, there's no "interest" to pay. But it's easy to get into a negative spiral where you are borrowing to pay off debts and where some people struggle just to pay the interest on their loans. image There are entire populations of people who "Debt Slaves". https://en.wikipedia.org/wiki/Debt_bondage

can-pay-cash-cant-afford-it

We have been called in to "fix" projects/products where the time spent fixing bugs exceeds that spent on delivering new features/value by 10:1. i.e. paying interest on Technical Debt accrued by cowboy developers who have long since left to sprinkle their "10x" magic on the next unsuspecting project.

image https://www.ironsidegroup.com/2017/05/11/cost-technical-debt-analytics/

The number of software projects we have seen "declared bankrupt" (i.e. having to be scrapped/re-written) is too many to count and it needs to be stopped.

It's "human nature" to take the easy path, especially when there is no real risk of repercussions. But it's the people who do the difficult thing(s) who achieve "extra-ordinary" results.

iteles commented 6 years ago

@nelsonic Happy to go with your take on this as it's the more literal one.

My view is very much based on a conscious decision that something will yield a very specific result and a commitment up front to resolve issues in the next couple of sprints (with the knowledge that it is more expensive in the long run). This is a somewhat rare occurrence. I also know that often this is never revisited and just spirals so is a dangerous precedent.

We come up against what I mentioned above more often anyway, so still keen to include:

the fact that changing requirements/direction and increased knowledge of the project throughout its lifetime require a team to factor in time to go back and adapt older code to be more performant/relevant/consistent.

@nelsonic Any objections? Maybe it should be a separate issue altogether.

Cleop commented 6 years ago

Putting together a first draft of this one in a PR, happy for it to be added to at a later date if preferred.

@nelsonic - surprised about your reality TV comment? I thought you were Honey Boo Boo's biggest fan? Didn't you fly out for one of her fan events last year? 😉