> Build the whole thing badly.<p>It doesn't have necessarily to be <i>poorly</i> written code though - you can start with lots of constant functions and later replace with actual logic, and still, at each iteration you'll have a complete testable flow.<p>Some test frameworks like Clojure's midje [1] and Python's mock [2] help a lot with this by making mocking functions inside the test painless, so you can start with what you wish you had and then fill the blanks.<p>I believe someone on the internet named this "Wishful Thinking Driven Development", quite ingenious.<p>[1] <a href="https://github.com/marick/Midje" rel="nofollow">https://github.com/marick/Midje</a><p>[2] <a href="https://docs.python.org/dev/library/unittest.mock.html#the-patchers" rel="nofollow">https://docs.python.org/dev/library/unittest.mock.html#the-p...</a>
This is a scattershot of some good practices, most unrelated to the title. But on that topic,<p>> 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.<p>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.<p>You (author) are on the right track though, it's a good idea to have a reflex against perfectionism.