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

The Way We Look at Technical Debt Is Wrong

bigeng.io

Post reply on HN
Print view View original

51–60 of 114 posts

Re: The Way We Look at Technical Debt Is Wrong

#51

Post by dccoolgai »

moron4hire wrote: post #45
dccoolgai wrote: post #25

From years of experience, I detect in the tone of this piece a certain notion that product managers / non-technical people tend to form when working with developers - namely, that developers don't care about speed-to-market and would rather agonize and winge over perfect architecture and coding standards... What I think you'll find, more often than not, on the business end of this attitude is a developer(s) patiently…

New PMs are like children, they tend to only learn the fire is hot by actually getting burnt. Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I s…

|| they can have this feature today and in 6 months we grind to a halt

Buy some daisies and chocolate for the PMs you work with... because here's how that would go over with the ones I've had:

PM: "Yes! Cut all corners and get it done today!" ...6 Months go by... PM: "I came up with a new idea for that! Today, please!" DEV: "But remember..." PM:"Today, thanks!"

Re: The Way We Look at Technical Debt Is Wrong

#52

Post by auganov »

The way I look at it, is that "doing things right" is a risk. It will always equal faster "speed-to-market" in the long term. I think we're just afraid to admit that "doing things right" very often ends up not working out. At all. If only it were so simple, that we could just take a little bit more time and have that perfect architecture and test coverage. In reality we often end up making something that's not "right" at all. Or worse - nothing.

I don't see taking on "technical debt" as being faster. It's just less risky. You're more likely to have something that does something after that month of work. Hence the common perception that it's faster. In an organization where there's mistrust (rational or not) it's easier (or even better) to take the safe road of "technical debt".

Re: The Way We Look at Technical Debt Is Wrong

#53

Post by moron4hire »

varunjuice wrote: post #43

IMO This is all you need to know about "technical debt" 1/ Poor code =/= technical debt. Far too often, poor code masquerades as "technical debt" 2/ Good engineers do the right thing which is always a judgment call based on circumstance & culture. 3/ Take guidance from your best engineers, and find a way for the business to adapt. Much easier to change the sales deck or pricing today, much harder to overcome bad tech…

Your #1 is spot on. Every "grind-to-a-halt" scenario I've been in has been because we expected X number of users or Y amount of data and once we released it turned out to be 100 times those numbers. The system you build for 10 internal users is going to look a lot different than the system you build for 1,000 users on the internet, and that's going to be completely different than what you build for 1,000,000 users. That doesn't make the small system poorly designed, it just makes it inappropriate.

Re: The Way We Look at Technical Debt Is Wrong

#54

Post by TazeTSchnitzel »

svdree wrote: post #41

In the past 15 years I've been in a situation twice where shipping something NOW was more important than taking the time to do the needed cleanup. Simply because the competition was breathing down our neck, and taking a break to refactor stuff would just give them an opportunity to bury us. And who's going to care about your code quality then? And it wasn't just crappy web apps or throwaway MVP stuff. The first one w…

> rushed software

> medical systems

Oh no.

Re: The Way We Look at Technical Debt Is Wrong

#55

Post by HCDevid »

d23 wrote: post #31
jaggederest wrote: post #5

I don't believe that, even in the short run, taking shortcuts actually saves you time. It's much like working 12 hour days - you feel more productive, but you're not actually getting any more done on a larger scale. There's an obsession with 'hurry up and get it done' that contributes little on a larger scale. I also don't believe it's possible to pick the 'important' areas of code a priori and make only those areas…

> I think that quality is something you can't 'bolt on' later. It has to be built in, top to bottom, throughout your organization, code base, and personal skills. I agree with all of your points and just wanted to add one more thing that doesn't seem to be addressed much. The author mentioned technical debt didn't have an "interest rate", but it absolutely does. As soon as you start to add debt to a particular part o…

What do you think of this extension of your analogy:

Financial debt has an interest rate, but you take it out because you believe the return on the proceeds raised adds more value than the cost.

Technical debt is meant to (ideally) be the same. As long as it's outstanding and compounding, it should be because your return on business value will be lower if you "pay it back", then if you do not and spend time/resources elsewhere.

if your discount rate is 30%+ per annum, this makes for some counter-intuitive conclusions about when it's smart or not to "finance" with technical debt.

Re: The Way We Look at Technical Debt Is Wrong

#56

Post by AshFurrow »

Sure, strategically taking on technical debt is sometimes beneficial to the company – just like sometimes taking on personal debt can be beneficial, too.

I think that discussions around technical debt really lack any mention of technical _credit_, the opposite of debt. Just like how you can take on debt in your codebase, you can save up credit, too. In an ideal world, you would always have savings so that you don't have to take on debt.

Re: The Way We Look at Technical Debt Is Wrong

#58

Post by moron4hire »

dccoolgai wrote: post #51
moron4hire wrote: post #45

Earlier quoted context omitted.

New PMs are like children, they tend to only learn the fire is hot by actually getting burnt. Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I s…

|| they can have this feature today and in 6 months we grind to a halt Buy some daisies and chocolate for the PMs you work with... because here's how that would go over with the ones I've had: PM: "Yes! Cut all corners and get it done today!" ...6 Months go by... PM: "I came up with a new idea for that! Today, please!" DEV: "But remember..." PM:"Today, thanks!"

You do a job. There is a reason you are there, and it's not to write code. It's to fulfill requests. Feel free to provide advice on how best to fulfill those requests, provide feedback, ask for clarification, etc. But at the end of the day, all you do is what you are told. It's not to anticipate what they will want in 6 months, because you'll be wrong just as often as right and you'll be in the same scenario. Just do your job.

So when you're told to cut corners today, then in 6 months you can't make magic happen to grant their every whim, you have to let it blow up. They want to be the leader. They are responsible for the failings of the team.

You have to play chicken with them. Because every time you capitulate, all they know is "I got what I wanted". They don't care how much you complained or how many hours off the clock you worked. And honestly, if you tell them it can't be done overnight, and then you do it overnight, you're a liar and they won't trust your judgement ever again. When you say, "can't do it", you have to not do it. Don't make magic happen.

Or just don't work at such places. I have thankfully been out of that bullshit for three years running now.

Re: The Way We Look at Technical Debt Is Wrong

#59

Post by crispweed »

Of course code quality is important, but some good points here, and I agree that 'technical debt' is quite different from financial debt. For example (beyond the points made in the post) maybe you have 'technical debt' on a bunch of code that becomes irrelevant and gets deleted (or reimplemented completely differently, or whatever) so that you never actually have to pay that 'debt'. I quite often find myself doing a kind of 'just in time refactoring' at the point where it becomes clear that code quality issues actually make it difficult to think about what the code is doing, or implement necessary changes.

Re: The Way We Look at Technical Debt Is Wrong

#60

Post by brlewis »

moron4hire wrote: post #45
dccoolgai wrote: post #25

From years of experience, I detect in the tone of this piece a certain notion that product managers / non-technical people tend to form when working with developers - namely, that developers don't care about speed-to-market and would rather agonize and winge over perfect architecture and coding standards... What I think you'll find, more often than not, on the business end of this attitude is a developer(s) patiently…

New PMs are like children, they tend to only learn the fire is hot by actually getting burnt. Instead of digging my heels in on not giving such PMs everything they want, I try to offer alternatives and put the choice on them: they can have this feature today and in 6 months we grind to a halt because we can't fit in anything new, or we slow down just half a beat and do it right the first time. "Up to you, buddy," I s…

A less condescending way to make that first statement would be, PMs learn from experience.
Post reply on HN