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

81–90 of 114 posts

Re: The Way We Look at Technical Debt Is Wrong

#81

Post by bunderbunder »

rsp1984 wrote: post #68
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…

From years of my experience, both in big corporate tech and startups, smart Engineers will always find business reasons to sell you their tech-debt free perfect rainbow unicorn architecture. Even worse, if you're then not equally technical as a manager you will never know whether you've made a solid choice by aligning with or against the engineer's view, and even worse your engineers will quickly take on a "see, I to…

I've seen entire products - established, successful products - sunk by a single decision to let the engineers build a gold-plated replacement for some component that had a messy architecture and eye-watering code on the inside but otherwise wasn't broken and didn't need fixing.

This is a spot where I'm definitely in line with the Scrum position: If it's really causing problems, then the developers should have no problem making a reasonable business case for fixing them. If working on it's really causing that much pain, then the developers will figure out a way to quietly fix it in a way that doesn't (and needn't) vex the product owner. If neither of those is the case then you best let sleeping bears lie.

(I'm an engineer too.)

Re: The Way We Look at Technical Debt Is Wrong

#82

Post by dragonwriter »

ekidd wrote: post #32

I'm unconvinced that accepting large amounts of technical debt allows startups to react faster. I've definitely seen startups that have almost found a good idea, but can't tweak it, scale it, or make it stable, because they're overwhelmed by technical debt and even simple changes have become engineering death marches. Letting your back-end code turn into a complicated, disgusting mess means that adding critical featu…

> I'm unconvinced that accepting large amounts of technical debt allows startups to react faster.

Accepting large amounts of technical debt enables you to deliver faster if your initial assumptions (both about what you want and how to achieve it) are correct, but slows you down if any of those turn out to be wrong.

OTOH, it might offset that slowness in whole or in part that by speeding up your ability to determine that they are wrong.

Re: The Way We Look at Technical Debt Is Wrong

#83

Post by ww520 »

Incurring technical debt early on is fine. A large portion of the code for new ideas or new venture are thrown away anyway due to misaligned market or product fit.

However, management need to understand technical debt and their impact on timely product delivery in later stage of development.

Re: The Way We Look at Technical Debt Is Wrong

#84

Post by 7Figures2Commas »

omouse wrote: post #72
moron4hire wrote: post #58

Earlier quoted context omitted.

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…

That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment. As you say, don't make magic happen . It doesn't matter how cool it would be if, or how you think you'll show them your ideas are better; when you say "it cannot be done" don't go…

> That's the everyday struggle; as developers we can produce so much wealth just by typing at a keyboard. Yet we let ourselves be controlled by people who don't know what's what and can't even prove their ideas have any return on investment.

That's the everyday misconception. Nobody produces wealth just by typing at a keyboard. Products don't design and sell themselves and it's arrogant to pretend that product people and salespeople aren't a huge part of the value creation process in tech.

There are of course developers who are capable of identifying a market opportunity, conceptualizing a product to exploit the opportunity, building the actual product and getting it into market successfully.

But if this is common, why are so many talented developers sitting at desks in open office spaces working 10-12 hours a day for low six figure salaries?

Re: The Way We Look at Technical Debt Is Wrong

#85

Post by angersock »

rsp1984 wrote: post #68
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…

From years of my experience, both in big corporate tech and startups, smart Engineers will always find business reasons to sell you their tech-debt free perfect rainbow unicorn architecture. Even worse, if you're then not equally technical as a manager you will never know whether you've made a solid choice by aligning with or against the engineer's view, and even worse your engineers will quickly take on a "see, I to…

Had a startup fail because we tried to do the right thing instead of "Fuck it, ship it". Worked at another place where the codebase finally curled up into a ball and refused to accept any refactorings short of a complete rewrite of some core systems--at which point we discovered some nasty bugs in production that we punted to our support folks to deal with. I've no idea if they ever eventually sorted it out.

Good engineers will recognize when it's "good enough". However, that requires biz folks that can provide useful feedback and actually get things in front of customers and get paid. Because, honestly, if we're like three extra features in, have no validation, and are cutting corners, you're damned right I'm going to put on the brakes and redirect the effort toward paying off technical debt.

Because, and this can't be overstated enough, whether or not the business fails in six months is not something we engineers can control--but I'll be damned if I'm going to come in and keep sinking my dwindling life force on a fucking technical lemon. If your biz folks can't establish trust in their abilities, then you might as well hone your craft.

EDIT:

Large amounts of technical debt are a sign of either rapid growth or bad management. If the company is growing, we can overlook the debt every time we, say, waste 30 minutes waiting on a build or fixing a weird nested CSS bug or some other damn fool thing. If the company isn't, then we lose respect for everyone above us in the technical leadership, because they let--by deliberate neglect!--the situation get so bad.

Re: The Way We Look at Technical Debt Is Wrong

#86

Post by a8da6b0c91d »

kstenerud wrote: post #50

This has been my experience in the startup world. My startup went from a few scribbled notes on paper to a full app in the app store in three months, including 50 lessons, 6 mini games, and a challenge/achievement system. Naturally, I had to cut a LOT of corners to do that, and accrued a ton of technical debt, but I was able to keep the high level architecture relatively supple, and as a result tackle the various mes…

I'm a firm believer in the adage "Build the first version to throw away; you will anyway."

https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_pil...

I feel like that's it's own idea and should not be confused with technical debt. The article seems to make this conflation as well.

Re: The Way We Look at Technical Debt Is Wrong

#87

Post by angersock »

TazeTSchnitzel wrote: post #54
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.

It's more common than you might think.

Most software, especially middleware and EHRs, are the worst sort of enterprise garbage.

Re: The Way We Look at Technical Debt Is Wrong

#88

Post by pekk »

bunderbunder wrote: post #81
rsp1984 wrote: post #68

Earlier quoted context omitted.

From years of my experience, both in big corporate tech and startups, smart Engineers will always find business reasons to sell you their tech-debt free perfect rainbow unicorn architecture. Even worse, if you're then not equally technical as a manager you will never know whether you've made a solid choice by aligning with or against the engineer's view, and even worse your engineers will quickly take on a "see, I to…

I've seen entire products - established, successful products - sunk by a single decision to let the engineers build a gold-plated replacement for some component that had a messy architecture and eye-watering code on the inside but otherwise wasn't broken and didn't need fixing. This is a spot where I'm definitely in line with the Scrum position: If it's really causing problems, then the developers should have no prob…

Just because you don't think anything is wrong in terms of external acceptance criteria, does not mean that there is not something wrong with the code that is of real consequence.

Contrarian anecdotes aside, the reason everyone knows the phrase "technical debt" is because SO MANY of us see projects wrecked by greedily demanding many features and changes as fast as possible in a continuous crunch mode, without considering long-term costs like defect rate or turnaround time on bugfix and feature implementations... or developer burnout.

It's better not to assume that developers are blathering when they ask for formal permission to carry out QA or maintenance tasks or upgrades, if they are the people who know what the work looks like on the ground level. If you are putting lots of time pressure on developers and implying that heads will roll if aggressive deadlines are missed, it doesn't make sense also to leave it up to those developers to magically find the time to fix lurking internal time-bombs.

This makes products worse, it makes developers' lives worse and developers are stuck with the blame for something they can't control. Maybe as a PM or whatever that suits you, to dump all the risk in the laps of your developers. But if you are yourself an engineer you should not make yourself part of this problem.

Re: The Way We Look at Technical Debt Is Wrong

#89

Post by bunderbunder »

pekk wrote: post #88
bunderbunder wrote: post #81

Earlier quoted context omitted.

I've seen entire products - established, successful products - sunk by a single decision to let the engineers build a gold-plated replacement for some component that had a messy architecture and eye-watering code on the inside but otherwise wasn't broken and didn't need fixing. This is a spot where I'm definitely in line with the Scrum position: If it's really causing problems, then the developers should have no prob…

Just because you don't think anything is wrong in terms of external acceptance criteria, does not mean that there is not something wrong with the code that is of real consequence. Contrarian anecdotes aside, the reason everyone knows the phrase "technical debt" is because SO MANY of us see projects wrecked by greedily demanding many features and changes as fast as possible in a continuous crunch mode, without conside…

I wouldn't want to make myself a part of that problem. If I found myself on a project where the business folks didn't care about things like defect rate or supportability, I'd be looking for a new job pronto. Those things aren't invisible to the business, they're a core part of the customer's value perception. A product manager who doesn't understand that is a product manager who doesn't have the slightest idea how to manage a product.

Similarly, living in continuous crunch mode is something I let myself get bamboozled into quite a bit in my younger days. I bake time to leave the camp cleaner than I found it into my effort estimates, and I know how not to let myself be pushed past my limits. If I worked for a place that couldn't respect that, I'd also be looking for a new job pronto.

I hope that you were being hyperbolic for rhetorical effect in your post, but if your work environment is really like the situations you were describing then I would also encourage you to be looking for a new job pronto. Life's too short to waste on that kind of stress.

Re: The Way We Look at Technical Debt Is Wrong

#90

Post by hinkley »

jmaistre wrote: post #79
ekidd wrote: post #32

I'm unconvinced that accepting large amounts of technical debt allows startups to react faster. I've definitely seen startups that have almost found a good idea, but can't tweak it, scale it, or make it stable, because they're overwhelmed by technical debt and even simple changes have become engineering death marches. Letting your back-end code turn into a complicated, disgusting mess means that adding critical featu…

One of the most valuable startup skills is to know which kind of debt has a low interest rate and which kind of technical debt has a high interest rate. Certain things - lack of tests, poor build system, poor deploy system, very poorly structured code - have a very high interest rate. Every time you create bugs, you waste time tracking it down and fixing it. Every time you check something in that breaks the dev envir…

Some people talk about Reversible Decisions, and I think what you're saying plays into that sentiment.

Unfortunately some people don't realize that in many situations not making a decision is itself a decision, and so they don't always notice it when it happens. That can be anything from the ones you mentioned, like testing and tools, to authentication, auditing, localization, robust error handling, resource/memory leaks, or monolithic designs that prevent scaling.

Post reply on HN