[superswordfish]

This is a scattershot of some good practices, most unrelated to the title. But on that topic,

> Think of changing a tire: you screw in the lug nuts loosely first, in a star pattern. Once you have all the lug nuts in loosely, you tighten them a little bit at a time, going around in that star pattern, until they’re all tight.

It just doesn't work this way, the bad code stays there. I'd be a little concerned to take over software you wrote, because that tightening plan lives in your head and the issues are global, not local to some module.

You (author) are on the right track though, it's a good idea to have a reflex against perfectionism.

[mikeryan]

It just doesn't work this way, the bad code stays there.

I read this differently. I didn't feel the author is saying the code is bad or "fast and dirty" to be cleaned up later so much as limited in features. Do limited features along the stack to get the whole toolchain in place before adding more features.

There's recent image with respect to UX which I think is relevant here https://twitter.com/jopas/status/515301088660959233

[MaulingMonkey]

> Do limited features along the stack to get the whole toolchain in place before adding more features.

This is the kind of codebase I like to take on. Limited features = less code = less to refactor, and what is there is probably better tested and has fewer bugs. I get to writing new features myself instead of just fixing someone else's work.