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

31–40 of 59 posts

Re: Reframing Tech Debt

#31

Post by twblalock »

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…

This depends on where the debt is.

If it's in the codebase for a single project, then sure, you can do some refactoring while you work, add more tests, etc. It's not too big of a time sink if you do a little at a time, and you can do it all by yourself.

But if the tech debt is in the architecture, or the API spec, or the authentication layer, or in some other area that impacts how services owned by multiple teams communicate? Now you need coordination with other teams to fix the debt. Everyone else has their own jobs to do, and if leadership doesn't make fixing tech debt a priority, other work will always take precedence.

Re: Reframing Tech Debt

#33

Post by lowercased »

infogulch wrote: post #14
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…

This is my preferred strategy, but gets muddled when managers micro-manage code reviews. Maybe that's just a sign of a toxic work environment. > You're not going to ask your execs if it's ok for you to take time to eat or brush your teeth. I like this! I could add: machine shop workers don't ask if it's ok to clean up the mess after a job.

A machine shop 'mess' is often obvious, and the risks are usually obvious and understood by most or all parties as well. It's not often the case with software (or... has not been in my experience).

Re: Reframing Tech Debt

#34

Post by bern4444 »

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…

What makes this work is the PM stopped asking about it and let you do it. They stayed focused on the deliverable work and gave you and the team the freedom to work on these tasks as you saw fit.

It wasn't squeezed in only when there was room in the sprint, it may not have even been a formal part of the sprint to begin with.

The PM wasn't trying to fill up the entire sprint with everything they could fit that they wanted to deliver. That's not always the case.

> I think it's a mistake to ask non-experts to prioritize things they don't understand.

It is, but many PMs behave where they have to know what everyone is working on each day (standups) and it has to be what their priorities are as well (via the tickets in the sprint which they plan). This PM you worked with was more open. That's wonderful

Re: Reframing Tech Debt

#35

Post by mostertoaster »

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…

It’s kind of like the person who buys a house. Buying it with no debt is not a bad way to stay pretty financially secure. Buying it with debt can be terrible if you’re piling on other debt. But once you have a really good amount of capital, debt can become a very powerful tool to become very wealthy.

I think the analogy can work in software development.

Re: Reframing Tech Debt

#36

Post by mostertoaster »

mostertoaster wrote: post #35
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…

It’s kind of like the person who buys a house. Buying it with no debt is not a bad way to stay pretty financially secure. Buying it with debt can be terrible if you’re piling on other debt. But once you have a really good amount of capital, debt can become a very powerful tool to become very wealthy. I think the analogy can work in software development.

Though if were honest for every savvy investor using debt wisely, there is the one blowing his paycheck up his nose, while driving a fancy car that will be repossessed tomorrow from his house that is way bigger than he needs.

Probably works for software development too.

Re: Reframing Tech Debt

#37

Post by manquer »

secondaryacct wrote: post #25
nerdponx wrote: post #24

Earlier quoted context omitted.

> 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. My experience has been that, once in a while, even this is not enough. You might just get accused of being a perfectionist or being overly meticulous about things that don't matter, and why can't we just do it the easy way an…

But you missed his point, it can be negotiated too. You get called a perfectionist because you project you refuse compromises, but have you thought of the business cost of any quality-oriented delay? (the opposite of quality-oriented work is result-oriented work) Yes doing shit on top of shit will be paid later, but sometimes, maybe that's fine to pay later while you are scrambling to make money in the first place ?

Manytimes you just get replaced in the project, when you stand your ground on security or debt.

It takes time for well maintained project to detoriate bad end enough for debt to impact business.

Even when it does , both the biz and new tech leaders are likely to refuse to acknowledge debt is important factor or blame it on you or start a rewrite without understanding what is going wrong to build on top of some shiny new tech everyone wants on their resume.

Re: Reframing Tech Debt

#38

Post by yourapostasy »

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.

> ...because you can’t define it with any precision no matter how hard you try.

For my clients, when we discuss "tech debt", I give it to them in concrete terms.

"You want Capability A at Month 3, but in order to pull that off, you're going to have to give on Requirement 1 and Expectations Lambda, and it will cost us Y months of implementation in Q4 instead of Y-2 months, will that work for the business?"

"Sure."

"So marked in the meeting notes, and filed under our Tech Debt Jira backlog Feature, we won't move forward with Capability A implementation until you send Sam when you need the technical debt paid off by, and we'll slot it in ahead of time, okay?"

"No problem, we'll get it to you with more detailed requirements on Capability A next week, thanks!"

Sure, when you don't track tech debt it is just sloppy work ("incompetence" is a little harsh, I tend to say the staff involved need more coaching and are possibly more junior than their roles require...bees, honey, and all that). It has served me well to get through to those managers who initially demand the impossible.

Re: Reframing Tech Debt

#39

Post by pydry »

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.

Re: Reframing Tech Debt

#40

Post by pydry »

twblalock wrote: post #31
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…

This depends on where the debt is. If it's in the codebase for a single project, then sure, you can do some refactoring while you work, add more tests, etc. It's not too big of a time sink if you do a little at a time, and you can do it all by yourself. But if the tech debt is in the architecture, or the API spec, or the authentication layer, or in some other area that impacts how services owned by multiple teams com…

There are multiple strategies you can use to chip away at big debts.

Coordinating teams does make it difficult though.

Post reply on HN