You're running across a field, full-tilt. Your goal is to run back and forth across this field 1,000 times by a certain date. Problem is, the field is filled with gopher holes. You keep tripping and falling. What do you do?

(It's a metaphor, see? The field is your codebase; the gopher holes are, well, all the usual crap you find in codebases. Technical debt, cruft, whatever you want to call it. Running across the field represents modifying the code.)

One approach--the most common approach I see--is to get up and keep running. Faster! Faster! There's a deadline coming and you've only crossed the field 42 times so far. Problem is, those damned gopher holes keep tripping you up.

There's a better way. We're going to run across this field over and over. We'll keep falling into the same holes. So, whenever I go down a gopher hole, I stop to fill it in. Sure, it takes a few extra minutes to shovel the dirt, but when I'm done, I'm guaranteed never to fall in the same gopher hole again.

It may seem slower, but we're running across this field hundreds of times... thousands. If we fill in gopher holes every time we encounter them, by the 200th time, you'll have filled in all of the holes on your most common route. Even if you can't fill in every hole, just filling in one hole a week will make your life better within a few months.

...

People don't always believe me when I say that codebases can actually get easier to modify over time. How is that possible? This is how. Mercilessly fill in gopher holes. When you're tripped up by your codebase, or development environment, or build system, or whatever, don't just keep coding. Fix the problem. It's actually easier, faster, and more fun to work with code created this way than it is to work with a brand-new codebase.

It's a great way to work. Try it.