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

1–10 of 114 posts

Re: The Way We Look at Technical Debt Is Wrong

#3

Post by swalsh »

"Financial debt, however, accrues interest and hurts more regardless of what it is incurred for."

I'd disagree, I think all technical debt accrues interest (similar to financial debt), but the interest rate is different. As the example about a usps api demonstrated, that has a near 0% interest rate. Of course if you were ever to need to update it (maybe usps updated its api) you'd get hit. A bad domain model has a high interest rate. All the ideas are the same though, i'm just being persnickety :D

Re: The Way We Look at Technical Debt Is Wrong

#5

Post by jaggederest »

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 free of technical debt. Doing good work is an attitude, a mind set, and something to practice - if you practice making poor quality code, it's going to affect you across your work, not just in the places that you do it.

I think that, by being professionals and putting aside the 'hack it out' mentality, we can improve not just the code that we're working on, but our mindset towards it. How many codebases have 'that scary part' that adds background anxiety to the people that work on it? Is that something you want to invite into your life on an ongoing basis?

Especially for things as important as integrations into external APIs - sure, they may not change much, but in my experience you really want to make sure they're done right when they're how you deliver your product to customers. Given how error-and-failure-prone many external APIs are, I expect a lot of work there just to robustly handle the other end of your integration being flaky.

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.

Re: The Way We Look at Technical Debt Is Wrong

#6

Post by aaronbrethorst » 

    Systems take too long to get to market, which causes
    marketing efforts to stall or become irrelevant, and
    competitors beat out the startup to an offering.
I disagree. Well, maybe I agree in part, but I feel like this misses the forest for the trees. Getting to market fast helps you get in front of users (and prospective users) faster, which—assuming you're listening to them and iterating—helps you achieve product/market fit before you run out of capital or a competitor does the same.

Wikipedia has a bunch of great links to more on the topic if you're unfamiliar with it: http://en.wikipedia.org/wiki/Product/market_fit

Re: The Way We Look at Technical Debt Is Wrong

#7

Post by Animats »

The article applies mostly to short-lived webcrap and appcrap, where time to market matters. There's software where reliability matters more than features - databases, for example. Source code repositories. Banking systems. Soon, automatic driving. (The coming "Internet of Crappy Things" is a real worry.)

Re: The Way We Look at Technical Debt Is Wrong

#8

Post by amelius »

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…

But often the choice is: do I implement this in an hour, or do I spend a week making a nice well-though-out framework for this, complete with test-suite (which may take multiple iterations to reach perfection).

And you may pick the latter, but what if management wants to make a quick prototype and turn that into a product later? At that point you'll still be having the "technical debt" talk with your manager.

Re: The Way We Look at Technical Debt Is Wrong

#9

Post by jaggederest »

Animats wrote: post #7

The article applies mostly to short-lived webcrap and appcrap, where time to market matters. There's software where reliability matters more than features - databases, for example. Source code repositories. Banking systems. Soon, automatic driving. (The coming "Internet of Crappy Things" is a real worry.)

I think that quality matters even in 'short lived webcrap and appcrap' - you only get one chance to convince your customers to trust you, and if your application even so much as behaves subtly wrong they're gone. I think that's the class of error that 'hack it out' most causes - it's not an application error, it's an error of logic or off-by-one or floating-point-math-where-it-should-be-exact.
Post reply on HN