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

101–110 of 114 posts

Re: The Way We Look at Technical Debt Is Wrong

#101

Post by imh »

HCDevid wrote: post #47
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…

While I agree with you on time vs. shortcuts, I do think it's a question of valuing explicit time vs. opportunity cost that's a depper issue here. My opinion is that whether it's programming or general white-collar work, most cases of doing it "the right way" vs. "the dirty way" tend to be about investing the "certainty" of lost time immediately for the "promise" of savings. For some things, the tradeoff is pretty de…

That's a dangerous attitude that makes sense for some startups, especially those with high burn rates.

"If we don't get traction/product out the door now, we won't be able to raise our next round, so we have to get this product out the door yesterday to de-risk the whole company falling apart when we run out of money in a few months." Then later you raise your round and do the same thing for the next round. Eventually, of course, it will catch up with you and slow key progress. If you're unlucky that leads to a down round and you're all screwed.

I see that as being a larger risk than competitors moving faster in the sort term (them moving faster short term may mean you move faster long term). Higher burn rates mean you have a clearer deadline for fundraising, means you're racing the clock, means you're incentivized to take on technical debt. I'd love to have a look at what really tends to kill companies more often, but it's just anecdotes and speculation from me today.

Re: The Way We Look at Technical Debt Is Wrong

#102

Post by alwaysmeh »

This is a terrible article. The awfulness starts at the title, and continues throughout.

What's wrong with the title: he asserts that "we" all defined technical debt incorrectly, when (in my experience) there's no meaningful agreement on that term. It's one of those terms that, if it's used, requires follow-up to be sure that both parties are talking about the same thing. The author even acknowledges this lack of agreement, but he asserts that we're all using it wrong.

The author then proposes a definition: "any code that decreases agility as the project matures".

Sorry, but there's no polite way to say this: that is, quite possibly, the most useless definition of technical debt I've ever heard. Every line of code decreases agility in one direction or another, every step forward is a step past some other opportunity. Thus, a definition that conflates necessary progress with actual problems is worse than useless. It's harmful. And frankly, I have trouble imagining an intelligent person who would use it. At this point I'm attacking the author a bit, but at this point the author has attacked the entire world a bit, so it seems fair.

The author has made clear that he thinks he's smart, that we're dumb, and he's figured out things we can't understand. So gross.

Captain know-it-all then proclaims, in bold font no less, that "The Most Important Thing is Getting the Thing to the User". No. Fucking. Shit. We fucking know that. We get that. Please don't do this shit where you conflate the whole damned world with the one guy in your office who you're passive-aggressively railing against with this awful awful screed.

Then this just gets into total dishit territory. We're supposed to not worry about getting everything right, but god forbid we need some migrations along the way, no... those aren't acceptable to this bloviation blowhard, we must get them all right on version one.

I now have a better understanding why BigCommerce is about the fifth company I think of when I think of places to host a shop. They're a fifth place company that hires fifth place management.

And Shaun, if I'm correct that you wrote this because you're tired of hearing your team talk about technical debt, then you are truly a horrible manager and you should just fucking quit. I'm not a person who typically advocates quitting, but this seems like nothing more than a passive-aggressive attack on one or more of your engineers who mentioned technical debt or code quality more often than you'd prefer.

And if you really just thought this was brilliant insight: you're an idiot. You used a dumb definition of tech debt to justify an argument that showed you don't understand the original metaphor. You are an impressively stupid man.

Re: The Way We Look at Technical Debt Is Wrong

#103

Post by vorg »

brlewis wrote: post #63

Can someone please tell me the audience for this essay? Is there a company out there where they're so careful to follow good practices and control technical debt that they're erring on the side of too much quality? And are they hiring?

> Can someone please tell me the audience for this essay?

There's a clue in this quote:

> The most successful cities in the world, such as New York, London, Vancouver, Sydney, etc 

A big city in each of the 4 largest native English-speaking countries of the world, in descending order of population.

Re: The Way We Look at Technical Debt Is Wrong

#104

Post by collyw »

sokoloff wrote: post #78
omouse wrote: post #72

Earlier quoted context omitted.

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…

If I understand your story correctly, that other dev accomplished the task in some characteristically short amount of time, plus an hour for fixing a bug. While you didn't specify what your "X" was, it sounds like the manager (and the company) got a better outcome by going around you and it was far from being "asked to do the impossible".

Because the quickest way to fix something is usually the most robust solution for the long term?

Re: The Way We Look at Technical Debt Is Wrong

#105

Post by collyw »

shangxiao wrote: post #69
bshimmin wrote: post #67

"This is why single-page applications have grown in such favor over the past few years; they allow quick agility at the UI layer without the need for API changes." I haven't seen anyone else comment on this sentence, but I'm baffled by it. The first and second parts don't seem in any way connected, nor at all in keeping with my experience of building SPAs - the UI layer is often intricately complicated and every bit…

Not only that but I've found SPAs to be more complex than their traditional counterparts, mainly due factors like: the extra layers & complexity involved, churn rate of & lack of maturity in JavaScript frameworks, lack of integration with backend of choice. Of course there are advantages to SPAs and this generally is my choice of architecture, however I definitely wouldn't say that SPAs are more agile at all.

yes, usually you end up a lot of MVC on both the front and back end.

Re: The Way We Look at Technical Debt Is Wrong

#106

Post by omouse »

7Figures2Commas wrote: post #84
omouse wrote: post #72

Earlier quoted context omitted.

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…

> 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.

Okay you've got a point, it is fairly arrogant; on the other hand, any sort of automation or small script or product is valuable enough that we don't need to be subservient.

> 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?

That's what I'm asking, why are talented developers allowing themselves to be subservient? That's why I'm wondering why technical managers all the way up to the CTO level are subservient to other departments when it's the product based on technology that determines the success of the company in the end?

And actually, your idea is optimistic; I wouldn't mind low six figures for 10-12 hours a day ;) maybe that's why we're so subservient, we look at our peers in other industries and they're making much less cash money and it's easy to see that we're lucky to be working in a nice air-conditioned office working with something we're typically passionate about.

Re: The Way We Look at Technical Debt Is Wrong

#107

Post by omouse »

sokoloff wrote: post #78
omouse wrote: post #72

Earlier quoted context omitted.

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…

If I understand your story correctly, that other dev accomplished the task in some characteristically short amount of time, plus an hour for fixing a bug. While you didn't specify what your "X" was, it sounds like the manager (and the company) got a better outcome by going around you and it was far from being "asked to do the impossible".

I'm not going to slag on the developer; the manager got a better short term outcome. The longer than 1 week outcome is that I've had to go back and re-visit that code and make sure it's "done done for reals it's done" due to the lack of unit tests and thorough thought given to it.

On a long enough timeline, the better outcome turns into multiple bugs.

Re: The Way We Look at Technical Debt Is Wrong

#108

Post by Schwolop »

I'm so glad Bigcommerce is finally taking technical debt seriously, 'cos that place is _full_ to the damn brim with it! (Some of it mine...)

That said, the only reason their business is where it is today is because of shortcuts taken in the name of speed-to-market. In their case, the end really did justify the means - eCommerce is ultimately a land-grab for market share, and BC dove in hard, spent _millions_ on marketing and customer support, and left Engineering to fend for itself. As an engineer, it sucked, but in retrospect and looking at their success to date, I'm willing to concede it was the right choice at the right time.

Re: The Way We Look at Technical Debt Is Wrong

#109

Post by crdoconnor »

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!"

This is what you do with the ones you work with:

>PM: "Yes! Cut all corners and get it done today!"

You: Can I get that in writing, please?

Re: The Way We Look at Technical Debt Is Wrong

#110

Post by spronkey »

ColinDabritz wrote: post #23

I don't think the metric 'any code that decreases agility as the project matures' is quite the same thing. I think most code lowers agility, as it is increasing complexity and the number of interactions and entanglements across your codebase. Adding features decreases agility. These are not 'technical debt'. I always enjoy Ward Cunningham's discussion of this: http://c2.com/cgi/wiki?WardExplainsDebtMetaphor (Ward fir…

I don't necessarily agree that adding features decreases agility. Sometimes it can massively increase agility - especially if your product is built in a way that a new feature can immediately gel with other features.

But apart form that, absolutely. Technical debt in the article isn't the technical debt that was originally coined.

I still think the common meaning of technical debt is just as important though. Code that can't be taken forward, for whatever reason, costs its owner.

Post reply on HN