The Way We Look at Technical Debt Is Wrong • Hacker News Board

Re: The Way We Look at Technical Debt Is Wrong

#111

Post by 7Figures2Commas » Fri, May 15, 2015, 4:53 PM UTC

omouse wrote: post #106

7Figures2Commas wrote: post #84

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

> That's what I'm asking, why are talented developers allowing themselves to be subservient?

Answer: trying to get a real product to market successfully requires a lot more than small scripts that automate processes.

It's not that automation and the like doesn't have value, but ask the average developer to get on the phone and sell something, or to have a meaningful conversation with a customer, and you might start to understand why other people in an organization (salespeople, product managers, etc.) have some sway too.

If you simply put a bunch of talented developers in a room, chances are you're not going to end up with a successful business.

Re: The Way We Look at Technical Debt Is Wrong

#112

Post by HCDevid » Fri, May 15, 2015, 9:26 PM UTC

imh wrote: post #101

HCDevid wrote: post #47

Earlier quoted context omitted.

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

It's definitely a dangerous attitude, this is also the problem with anecdotes, we all start postulating strawmans.

I would point out though that in the financing-focused case you gave, although you have a definitive slow down from technical debt, it's still an open question whether or not it's actually a net slowdown vs the "status quo" scenario.

In practice of course, every individual company, with different teams and different contexts, has to find the right "cognitive bias" for themselves.

Re: The Way We Look at Technical Debt Is Wrong

#113

Post by garthk » Sat, May 16, 2015, 4:38 AM UTC

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…

The payments on technical debt never seem to come due when you expect, nor at the size you expect, hence arguments we should think instead in terms of unhedged call options, e.g. http://www.higherorderlogic.com/2010/07/bad-code-isnt-techni...

Everyone thinks they can pay after the release. If you cut those corners hard, though, you'll often regret it before your release. Cut harder still, and you won't even make it to the end-of-sprint demo before there's a knock at the door.

Re: The Way We Look at Technical Debt Is Wrong

#114

Post by moron4hire » Sat, May 16, 2015, 12:19 PM UTC

7Figures2Commas wrote: post #111

omouse wrote: post #106

Earlier quoted context omitted.

> 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 subs…

> That's what I'm asking, why are talented developers allowing themselves to be subservient? Answer: trying to get a real product to market successfully requires a lot more than small scripts that automate processes. It's not that automation and the like doesn't have value, but ask the average developer to get on the phone and sell something, or to have a meaningful conversation with a customer, and you might start t…

>> If you simply put a bunch of talented developers in a room, chances are you're not going to end up with a successful business.

Quite, yet this seems to be how many first-time startups operate.