Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reframing Tech Debt

increment.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Reframing Tech Debt

#41

Post by gridspy »

pydry wrote: post #39
ahdh8f4hf4h8 wrote: post #5

Personally, I no longer use the phrase "technical debt" when speaking to management. It's just too vague of a term. Instead I just explain the actual problem and the consequences - too much near duplicate code leading to slow maintenance, non-scalable design choices leading to slow processes, rigid design choices which hamper the team from implementing the upcoming stories, excessive complexity leading making the cod…

I've tried doing this. Their eyes tend to glaze over. They don't really care about the nitty gritty of the code nor should they have to.

Then explain it in terms of the benefit. "I noticed it was hard to add features like and I'm going to make it much faster, easier and more reliable for next time"

Re: Reframing Tech Debt

#42

Post by outsomnia »

wellpast wrote: post #17

“Tech debt” is the software industry’s way of euphemistically describing their incompetence. It’s a way to act like one “meant” to implement a shitty architecture instead of admitting one’s lack of ability and experience. It’s the mantra of the expert beginner of which there are so many. You think I’m wrong, but you know I’m right because you can’t define it with any precision no matter how hard you try.

> You think I’m wrong

No, I was on my way to upvote your comment when I got to

> but you know I’m right because you can’t define it with any precision no matter how hard you try.

It's when somebody decides to optimize for one thing that temporarily mattered to them at the time, at the expense of other things that matter afterwards.

Eg, having that demo next week may truly be existential for the project, but all the foundations you didn't dig and the rebar you skipped putting in to tick that box mean you cannot successfully build on it without going backwards first.

Re: Reframing Tech Debt

#43

Post by KronisLV »

wpietri wrote: post #9

I think this is a mistake a lot of people make: > Carving out time to pay down tech debt requires buy-in from leadership. Not in my experience! I think one can do pretty well a) refusing to put debt in to begin with, and b) for any new work, including necessary cleanup of what you'll be touching in the estimates. Some years back I had an explicit understanding with a product manager: the engineers would track tech de…

> That should just be part of the deal; any exceptions should be temporary and carefully negotiated.

This feels like it's probably dependent on the culture in question. Writing tests, caring about readability and the long term sustainability of the codebase and even managing the technical debt all can be the exceptions themselves in certain teams.

Sure, you can turn around and run for the hills, but for many there, those are the circumstances that they put up with to get food on the table, or work with for different reasons, so those circumstances shouldn't be ignored.

Ergo:

> a) refusing to put debt in to begin with

Management: "Hey, what is this ticket taking so long to complete? Can't you just develop the solution more quickly, without spending so much time on refactoring, planning or whatever it is that you do? Developer X did something similar faster just last week!"

> b) for any new work, including necessary cleanup of what you'll be touching in the estimates

Management: "Why are you suggesting estimates that are 1.5x - 2x higher than the rest of the team? Refactoring? Integration tests? Test data generation? Logging? Do you really think that those are necessary for this many tickets? Don't you want to reconsider your estimate, not to be the outlier? No? Okay, we'll just take the averaged estimate of them all."

Personally, i believe that developers should be trusted more and just care about the long term sustainability of what they're developing beyond their probably employment duration at the company (given how popular job hopping is nowadays), yet sadly that's not been the reality in my experience, probably because of prioritizing functionality and business value now, rather than stability and reliability later.

Re: Reframing Tech Debt

#44

Post by dgb23 »

ahdh8f4hf4h8 wrote: post #5

Personally, I no longer use the phrase "technical debt" when speaking to management. It's just too vague of a term. Instead I just explain the actual problem and the consequences - too much near duplicate code leading to slow maintenance, non-scalable design choices leading to slow processes, rigid design choices which hamper the team from implementing the upcoming stories, excessive complexity leading making the cod…

It’s a matter of keeping your work environment clean and orderly and to separate different parts into different areas.

Re: Reframing Tech Debt

#45

Post by sirwhinesalot »

ravenstine wrote: post #18

Technical debt is a euphemism for bad code, bad practices, and bad decisions. When we use the term tech/technical debt, we are pretending that the real answer isn't "we didn't do it right the first time". The primary reason this phrase even exists is because if we told our superiors the truth then heads might roll. Non-technical people don't really understand what "technical debt" means, but the word debt at least ma…

That's some victim blaming right there. If a project has tech debt it is because of management decisions 9/10. They are the ones promising higher management some feature would get done by The Date(tm) without consulting with development if that is feasible. Development then buys time with tech debt (cutting corners, copy pasting, not writing docs/tests).

Then things start getting delayed because developers are paying the "interest" (i.e. regressions due to bad tests) on that original "debt" that was paid to give management what they wanted.

Re: Reframing Tech Debt

#46

Post by jillesvangurp »

Technical debt is a bit of a fuzzy problem that is hard to explain without a lot of platitudes to a non technical person.

Instead of doing that, the key to staying on top of keeping your tech stack in a sane state is to assign ownership of it to a person that knows what they are doing that can effectively counter the pressure from non technical persons in the organization to move faster. It's all about prioritizing correctly in the end and that's not a job you can give to a non technical product manager.

I actually am a CTO that is also responsible for a lot of the day to day product management. So, I get to wear both hats.

My job is not to blindly execute somebody else's vision but to actually create and define the vision and adjust to needs and wants of our business based on what is technically possible with our stack and ensure that that stack is ready to do so. Additionally, I need to stay ahead of this game and a lot of what we do technically is about being ready for what I can see coming next rather than just reacting to current needs. The game here is avoiding over engineering while at the same time spotting and removing technical bottlenecks.

Technical product management is a thing; or rather it should be in almost any team. It's a natural progression for a technical leader to also start paying attention to what they are building and why. I've been interacting with product managers for years and have many product manager friends. Working with them instead of against them is key. Technical product management requires somebody with technical know how as well as a sense of the business and its priority. A non technical PM is the wrong person for this job. If you have such a person guarding technical quality and business alignment, things run much smoother than if you have a lot of people bickering with each other over technical perfection or doing quick fixes.

Re: Reframing Tech Debt

#47

Post by sirwhinesalot »

wellpast wrote: post #17

“Tech debt” is the software industry’s way of euphemistically describing their incompetence. It’s a way to act like one “meant” to implement a shitty architecture instead of admitting one’s lack of ability and experience. It’s the mantra of the expert beginner of which there are so many. You think I’m wrong, but you know I’m right because you can’t define it with any precision no matter how hard you try.

PM: "We promised higher management that feature X would be done by The Date(tm)"

DEV: "We can only do that by cutting corners, reusing code for purposes we shouldn't, and making it not extensible in the future"

PM" "Yeah but we promised higher management so it needs to get done"

some time later...

PM: "Hey can we add feature Y by The Date(tm)"

DEV: "It doesn't fit with the rushed work we did for feature X, we'll need to rewrite quite a bit of code to make those two fit"

PM: "Yes but we promised feature Y by The Date(tm) to this customer, so it needs to get done"

DEV: "Well we can hack something together which does 90% of Y on a full moon and breaks otherwise, I really don't recommend doing this."

PM: "We have no choice"

some time later...

PM: "Why are all features taking so much longer to complete than they used to"

DEV: "Massive technical debt"

PM: "Ah yes, the software industry's way of euphemistically describing their incompetence."

Re: Reframing Tech Debt

#48

Post by JanisL »

After studying a lot of economics over the last few years I realized that most people have a poor understanding of the concept of debt so I stopped using the term technical debt almost entirely.

Re: Reframing Tech Debt

#49

Post by pydry »

gridspy wrote: post #41
pydry wrote: post #39

Earlier quoted context omitted.

I've tried doing this. Their eyes tend to glaze over. They don't really care about the nitty gritty of the code nor should they have to.

Then explain it in terms of the benefit. "I noticed it was hard to add features like and I'm going to make it much faster, easier and more reliable for next time"

It doesnt really help much saying that it should do these things if you can't say how much and in practice I find you rarely can.

"How much faster?"

"Dunno"

Plus, at least half of tech debt is about risk not time spent which is even harder to quantify.

For the kind of tech debt you are describing (e.g. making adding a 4th payment system easier) it makes much more sense to wait until it is needed again and to just do it (this offsets the risk of it never being needed at all).

Re: Reframing Tech Debt

#50

Post by ravenstine »

sirwhinesalot wrote: post #45
ravenstine wrote: post #18

Technical debt is a euphemism for bad code, bad practices, and bad decisions. When we use the term tech/technical debt, we are pretending that the real answer isn't "we didn't do it right the first time". The primary reason this phrase even exists is because if we told our superiors the truth then heads might roll. Non-technical people don't really understand what "technical debt" means, but the word debt at least ma…

That's some victim blaming right there. If a project has tech debt it is because of management decisions 9/10. They are the ones promising higher management some feature would get done by The Date(tm) without consulting with development if that is feasible. Development then buys time with tech debt (cutting corners, copy pasting, not writing docs/tests). Then things start getting delayed because developers are paying…

No it isn't. Just because tech debt is the end-product doesn't at all imply that the root cause isn't management, though I can understand why it might be misinterpreted as such.

> Development then buys time with tech debt (cutting corners, copy pasting, not writing docs/tests).

> Then things start getting delayed because developers are paying the "interest" (i.e. regressions due to bad tests) on that original "debt" that was paid to give management what they wanted.

The problem with this analogy is, unlike financial debt, said tech debt is often caused by management, and I'm sure you'd agree. Imagine trying to pay down your credit card and Visa tells you to make more purchases or else you may lose your card entirely (and still have to make your monthly payments). Does management view tech debt as something they share or are responsible for? I doubt it.

What the use of "tech debt" actually does is create an artificial sense of legitimacy around all the problems that exist in a failing process. It obfuscates specifics from management, dazzling them with terminology they believe they understand. It allows developers to believe that nothing is truly their fault. It gaslights developers into seeing a counterproductive or even abusive relationship with management as just debt that they own.

It'd be one thing if it actually did work like debt and, yes, I'm sure it does work that way with some teams. I don't think that's the norm.

Post reply on HN