Technical Debt Is A Business PROBLEM

Подписаться 202 тыс.

Просмотров 8 тыс.

50% 1

What are the effects of technical debt on business? Technical debt is not something only those within technical teams need to worry about. It impacts the entire organisation. It's important to know the cause & how to avoid it.
This is a clip from Adam Tornhill's FULL Engineering Room appearance that you can watch HERE ➡️ • Prioritizing Technical...
___________________________________________
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
___________________________________________
#softwareengineer #softwaredevelopment

Наука

Опубликовано:

18 ноя 2023

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 38

@davetoms1 6 месяцев назад

Fantastic conversation. I've been Product Owner and I've been Scrum Master. My biggest frustration was getting the _business value_ out of paying off technical debt. I always want to support the team paying it off when they say we need to. But many developers say things that equate to "Because we don't like it" or "Because it's wrong" no matter how passionately I'd ask "So help me understand why there's benefit to changing it?" or "What will happen if we do nothing, so I can justify empowering you to address it now." Of course there's benefit, otherwise they wouldn't want to change it. So I cherish the developers who are able to communicate the actual risks, the potential impacts, the "interest" we'll avoid paying, like Adam Tornhill does here. Sometimes the business value is "Bugs take longer to fix" or "Future changes will be riskier". Developers who say "It'll work the same before and after so the business won't care" is a frustrating response to sincere questions about the _value_ of paying it off. Because I completely agree, technical debt is a business problem. Teams need to explain what value there is to paying off the debt. And the business needs to accept it as a priority and drive conversations around the "why?"

@bjorn1761 6 месяцев назад

That would be a reason for the oposite (actually what Robert C. Martin proposes): that design/technical debt is the responsibility of the technical people/engineers, as it is their expertise and responsibility. In that view, engineers should not ask product owners/financial people (they really are not interested in quantitizing cyclomatic complexities, or having design reviews) for permission on lowering design/technical debt but just incorporate the activities in their daily work and planning and only communicate about the end result. Architectural debt however, as its interest rate/costs are way higher than typical technical debt, probably must be communicated to financial people. Technical people could use architectural tradeoff matrices for that to explain. I myself work and communicate that way with managers, and incorporate rework in my estimates. When managers say: the other guy does it in half the time , I say: well let him here do it. They always come back as the other person that dont take into account rework/design debt tend to work on it 10x the original estimate.

@archi-mendel 6 месяцев назад

Product managers and scrum master shouldn't be prioritizing technical improvements among product improvements. There is simply no such choice. Prioritizing features over technical excellence only work in early stage startups. Scale-up stage requires full focus on quality. The reason is that when the early startup stage is over, quality is n0ow a main capability of the product. It's as important how consistently and seamlessly the product solves problems of users, as what problems it solves.

@archi-mendel 6 месяцев назад

@@bjorn1761Exactly so, engineers should have enough time to ensure technical excellence, this is all they need. They shouldn't be agreeing with product people or anyone else on the improvements they make.

@disgruntledtoons 6 месяцев назад

"But if the developers really care about the company they can just work harder." -- The Cardinal Rule of Imbecilic Management, as applied to technical debt.

@dafyddrees2287 6 месяцев назад

… and this is compounded by all those non-technical people piling into the scrum industry…

@errrzarrr 5 месяцев назад

The Scrum mindset basically. Option B: You are doing Agile wrong. You need more training!

@thomasf.9869 6 месяцев назад

One of the impressive examples of technical debt management is the company Slack. They have technical debt budgets akin to error budgets in the SRE space. When technical debt exceeds the pre-agreed tolerance threshold all feature development stops until its back below the threshold. This is a sensible approach. It acknowledges that some technical debt is inevitable, but stops it getting out-of-hand.

@bobbycrosby9765 6 месяцев назад

Technical debt can be tricky at the architectural level. But anything less, I tend to not worry too much but also recommend the "boy scout" rule: leave the code in a slightly better state than you found it. If you revisit code because of a bug or a new feature it doesn't support, make it slightly better. This means you don't have to gold plate everything, but also that hotspots naturally get cleaned up over time. If you only ever allow your code to get worse over time, then you have a "you" problem. At this kinda scale, I don't consider this technical debt a PM-level problem. It's basic professionalism.

@ggus1991 6 месяцев назад

The boy scout rule may be sufficient when developers have resources and autonomy to apply it. Otherwise, it isn't sufficient to create sustainable software. It becomes clear to anyone who had to create features or fix bugs in a codebase full of tech debt at implementation level that both tasks become harder because of that debt. I'm currently in the process of leaving a project where management explicitly prohibits developers from implementing technical improvements that are not "covered by the assigned technical budget". And that budget ran out in the first few weeks of the quarter. It's an anti-"boy scout rule" environment, fostered by thinking only architecture matters. I'll let you imagine how healthy the architecture is. It's one of the reasons why I'm leaving the project.

@JohnKerbaugh 6 месяцев назад

- Time - Resources - Quality - Not all problems can be improved at the end of a bad process. Not without change in the environment.

@thomasf.9869 6 месяцев назад

Boy-scouting is a very effective way of prioritising technical debt, in so far as you are refactoring code that is actually relevant to the user story currently being worked on, as opposed to refactoring code that may never be touched again. It works well for small amounts of technical debt, but it is difficult to conceal a major refactoring as part of a user story. For addressing big debt, allocating time outside of user story work should be done, and agreed upon by the team as a whole.

@fulconandroadcone9488 4 месяца назад

@@ggus1991 What are the odds we were coworkers at my last job?

@raphaelbatel 5 месяцев назад

I like to think of it rather like deteriorated/faulty infrastructure (not hardware, more like roads, for the metaphor) than 'debt'. Unlike debt, roads and bridges can be left to deteriorate if you dont prioritize it (with debt, a collector will come for you). But at some point, its just worth it for everyone to fix it, even though it costs money and can be disruptive.

@factorfitness3713 6 месяцев назад

Non-technicals don't really understand technical debt or the consequences of it. They wonder why you didn't just do it perfectly the first time. Usually if you're able to explain the concept and the consequences of ignoring it (just like any other problem), any responsible product owner will find ways to prioritize it.

@Mark73 6 месяцев назад

The simple answer is that, as more and more requirements pile on, the original code becomes more and more imperfect. The code is made to do things it was never intended to do.

@factorfitness3713 6 месяцев назад

@@Mark73 I agree with what you're saying, and fundamentally we're both referring to entropy, but talking to business about code is never a winning strategy. There are usually more accessible ways to describe the problem than talking about code.

@witblitsfpv1265 6 месяцев назад

The problem is in the name. People have grown use to "debt", i.e. it is not seen as a bad thing, just something we live with. For management they don't see a concrete cost so they don't understand it which makes it appear like free debt you never have to repay. Not all technical debt should be addressed, but that is a tough call and often a slippery slope.

@dafyddrees2287 5 месяцев назад

A professor of Computer Science once confided in me that he thought “Objectory” (the software method) was like cult - with loads of courses and status levels and you had to pay to go up to the next level. I often wonder what that guy would have said about Scrum…

@troyrose20078 6 месяцев назад

I'm not sure of the best way to articulate this, but I think there's a direct relationship between technical debt and total cost of ownership of a product or service. The more you 'own' IE are responsible for the maintenance and care of something, the higher the total cost of that ownership is.

@chpsilva 6 месяцев назад

It's surely a less abstract concept for non-technical management people.

@nikH216 6 месяцев назад

I've had the most success when I relate it to home or car maintenance. You need to replace your water heater, furnace, roof etc. regularly. You need to change your engine oil, filters, or spark plugs regularly. We need to do the same things to software systems.

@kavinho 6 месяцев назад

It might work if your counterpart is sympathetic to your concerns. But if you’re facing a doubtful customer or other stake holder. You’ll be needing more than a shaky metaphor. The usual response is why didn’t you build it right from the start. The real answer is often, quality takes time, time to discover the bugs and non-functional requirements. And what makes this even harder is that we don’t know upfront the time it’ll take as long as we’re not doing a customization of a standard system (which usually have it’s own issues).

@arasefe 6 месяцев назад

Technical debt is the problem of the next manager, that's why the incumbent PM/PDM never cares about it. It is similar to governments who does nothing about the long term issues.

@mecanuktutorials6476 5 месяцев назад

Lol. Brilliantly put.

@LewisCowles 6 месяцев назад

What are all the sticky notes in Dave kitchen?

@IronCandyNotes 6 месяцев назад

I have seen companies with 0 focus on reusable code... It is just hell when management has no connection to the development at all. Code should be seen as a company asset... that you keep as compact, fresh n good as possible... your literally crafting behavior and spell like invocations... The guy who invented JSON made the lil gods comparison... n yet its treated like some napkin scribbling you just do to finish that ticket. Maybe tickets as a concept are the real problem here. The metaphor just smashes importance. 1 winning ww2-ticket coming up! With extra casualties!

@Mark73 6 месяцев назад

It's even worse when the managers ARE technical. The DO understand the problems with technical debt and still don't do anything about it.

@errrzarrr 5 месяцев назад

Scrum has made of software development a feature fabric. So, instead of _developing_ an asset, we are throwing out features, the more the better. Does not matter to incur in debt or the actual value of the feature, just more output so the burn down chart looks better on the dashboard.

@fulconandroadcone9488 4 месяца назад

Technical Debt: Shit we piled up because we didn't make sure to clean things or were not allowed time wise and now we have to walk over trash.

@HemalVarambhia 6 месяцев назад

Within it being a business problem, I feel that there is a skills problem, too. Can developers refactor the technical debt to a manageable amount?

@fulconandroadcone9488 4 месяца назад

Not if you are not allowed to clean things up as you go.

@PaulSebastianM 6 месяцев назад

🎉 Thank you for letting us attend these invaluable meetings!

@albertolanda 6 месяцев назад

I finally hear someone admit it

@praecorloth 6 месяцев назад

Technical debt implies the existence of technical loan sharks.

@BuildingBetterTeams 6 месяцев назад

Because it's not debt. If I want to buy a car and I buy an old rusted-out barely working ford pinto instead of a mclaren f1, I don't have "car debt" where I owe myself a repayment with interest towards that mclaren in the future. Somehow we in tech have deluded ourselves to thinking that when we rub a computer on a bad purchase it becomes a "debt". No, you bought a ford pinto. That's just a lousy asset. That's it. End of story. Now, how does that impact your operational success metrics on the race track? Yeah, we can talk about that. This investment has 0 ROI, we will never win a race.