I'm kind of on the fence about this approach. In the worst case you end up wasting time on a lot of dead ends. It's in such a situation that I kick myself for n

I'm kind of on the fence about this approach. In the worst case you end up wasting time on a lot of dead ends. It's in such a situation that I kick myself for not spending time thinking about the problem before starting to write code. The best times I've had with writing design documentation has been when I thought about the problem enough that I could specify the properties necessary for a correct implementation. Depending on the scope of the problem I might use property tests or model checking. In any case, thinking about the problem up-front tends to prune away dead-ends before you head down them. (Of course, you can't do much about a bad specification except try to avoid them... learning how to write good ones takes experience, wisdom, and constructive input from knowledgeable colleagues). Update: I’m on the fence because I’ve also had a lot of success with implementing partial solutions: just get something good enough that works for some use cases and improve as you go.