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 decent (taking time to improve core knowledge or relevant skills that are related to goals).

But for a quickly growing company, how many situations are there where a "hack it out" fix that costs time in the long run is a net win in opportunity cost and hence long-term value?

If a shortcut that will cause you headaches in 9-18 months also allows you to add critical features at an accelerated pace for the next 6 months, is it: (1) inefficient because you net lose man-hours or (2) efficient (a) maximizes your near-term growth trajectory, (b) thereby increasing potential access to resources and hence long-term growth

To be clear, I do agree with your statements about shortcuts usually not saving time especially when you deal with teams/setting standards.

My point is more that while time saved/lost is easier to mentally calculate, it alone is not really what's driving value in many situations.

There's also the inherent problem of using qualitative terms that mean different things to different people.

But hey, that's part of the fun on the internet.

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.

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.

It strikes me as a little absurd to say that taking shortcuts is always a bad idea. Let's look at a few shortcuts you might take.

Allow the page to break if the user's browser does not support websockets If you know that 95% of your target audience uses modern browsers this seems like a reasonable compromise.

Don't write enough unit tests Maybe you're using a library that is difficult to mock. Maybe most of your logic is happening at the db layer. Eventually you may want to thoroughly test this piece of code, but it's a ton of work to mock a database in a meaningful way.

Write a monolithic service instead of a modular one While it's bad to let a single service grow too large, when you're starting out, it can be helpful to write it all out, and _then_ see how it can be broken apart. (It's often hard to foresee everything at the design stage.)

Finally, a lot of code ends up being never used. Nobody cares about well-factored well-tested code that isn't used. Sometimes a dirty version is the quickest way to tell if a project makes sense at all.

> 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 of the code base, it must be paid back immediately the next time you or someone else has to work on that same section. This may genuinely not matter for a one-off script, but if it's code that will ever be worked on again it can start a snowball effect that causes the interest to compound and usually manifests itself as code that's buggy, unstable, and hard to work on.

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.

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.

It's rarely that extreme a difference in time, but even if it were, what you are really talking about isn't the whole story, except in truly throw away code (almost never happens). It's more likely to be something like:

1 week today to do it properly, a couple of hours a month from now to tweak it, a couple of more hours 6 months later to add a new tested feature,

vs,

1 hour today to hack it in, 3 hours on friday to rework it, 1/2 a day next week to debug a problem, and hour the next day to fix your fix ... plus the entire following day when that didn't work properly

Followed by 1 day to do a "proper rewrite" in a month, to add the tweak that should have been easy but breaks some of your assumptions plus 2 days to debug why something doesn't work properly anymore interacting with another subsystem.

Followed by someone else spending most of a week debugging a subtle bug you introduced by stepping on some state "nobody was using anyway"

Followed by 6months later when the new feature is needed someone looking at all this and throwing up their hands because they can't understand what it's doing. At which point they say... "screw it, I can re-write this in a couple of hours".

Lather, rinse, repeat.

Most of the time, the "fast way" is pretty reliably going to cost you more time. Just not more time today.

I think that's a straw man argument - the choice isn't between an hour and a week, it's a choice between an hour and two or three hours. I don't think that making a framework for every change is a good idea, but I do think that, if you've only got an hour to work on something, you'd better make some quality tests for it, because under time pressure you're even more likely to make the sorts of errors that tests catch.

That said, I'm not implying that you should slow down, just do the best possible work at all times. Don't do a crappy job just because you're time-limited - we all only have 24 hours a day, and there's always more work than can reasonably fit in. The moment you start going "I am going to lower my standards right now", you've started a trend.

I think it's interesting that people are always saying "hire the best possible people you can", and then saying "but don't ask them to do the best possible work they can do".

But a good programmer always sees a number of solutions to a particular problem. Let's say he sees 10 solutions. Solution 1 costs an hour to implement, but gives crappy code and he knows it. Solution 9 gives good quality code, but takes a week to implement, and he then has to sell this to his boss.

And then there's solution number 10, which requires the programmer to invent a new programming language, and requires at least a couple of months to develop. "You hired the best possible person for this job, so let me do the best possible job".

I just bet most people here wished they could always deliver the best possible code.

>But a good programmer always sees a number of solutions to a particular problem. Let's say he sees 10 solutions. Solution 1 costs an hour to implement, but gives crappy code and he knows it. Solution 9 gives good quality code, but takes a week to implement, and he then has to sell this to his boss.

A good programmer will try and improve code the code incrementally, and won't bother trying to sell anything.

I think what you hear me saying is "never do anything less than perfect work". I'm saying "given your current constraints, don't choose a worse option when a better one is available". Those constraints include time, your skills and beliefs, the environment you work in, the project you're working on, and the problem you're trying to solve.

I am sure that most developers want to deliver working code of reasonable quality (most likely not hacks)

I am sure that most product/project managers want feature as soon as they can think of it

A) If you think reaching perfection is a viable goal, ever, you're thinking about this all wrong.

B) You can spend an hour and a half instead of an hour and include one test and make some incremental improvements as you go.

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.