[Zakharov]

If you write code too slowly, go faster. If you write code too quickly, go slower.

You can tell if you're too slow when you've spent two weeks thinking about the program and have neither working code nor a detailed design, or if you've created a detailed design only to realize upon implementation you'd gone about it entirely the wrong way.

You can tell if you're too fast if you find yourself spending more time cleaning up messes of poorly-thought-out spaghetti code.

[andrewljohnson]

This is like in go. If your walls are too brittle, play more conservatively. If your walls are too thick, loosen up. You can make generally better moves in go just by recognizing if you are too conservative or too aggressive. Same with poker.

[avalaunch]

Upvoted to make up for MBlume's mistake. :)

[Zecc]

Upvoted again, because I felt like it. But it's still one upvote short, I guess.

[mgkimsal]

Fixed. :)

[MBlume]

meant to upvote you and downvoted by accident, just so you know

[stevenwei]

Yes. To add to that:

Sometimes you'll want to plan ahead because the nature of the problem means you'll have a harder time cleaning things up later.

Other times, you want to move quickly because creating castle-in-the-sky architectures is not the best use of your time (especially if it becomes paralyzing).

Experience helps you determine which type of situation you're dealing with.

[beckje01]

The problem that comes up is by the time you hit the tipping point of more cleaning then feature additions you end up having to do the fast solutions to fit deadlines.

I think when you take on the debt of poor code you have to remember that what it will take to fix that problem will continue to increase the longer you are away from that code.

Now I don't think you should consider fixing things for scale poor code that is it's own beast which makes the most sense to handle once you have the problem as you can't really tell what the problem will be until you have it.