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