I personally take a more pragmatic approach, though perhaps its "post-modern". How well-architected, tested, groomed, etc my code tends to be is proportional t

I personally take a more pragmatic approach, though perhaps its "post-modern". How well-architected, tested, groomed, etc my code tends to be is proportional to the confidence the business has in the problem space. If I have a detailed, firm spec that I know won't change at all, I'd spend some time planning and then build a DRYed up, abstracted, well-tested, etc solution. I know the solution is going to be sticking around for a while, more or less, so it makes sense to devote the effort to build a solid foundation. If the thing I'm building is squishy, looking for heavy user feedback, will likely be iterated on quickly (i.e., very agile manifesto agile), I won't spend the overhead time for those things. There's a nonzero chance the code ends up in the trashcan, and the most important thing is to ship something and get feedback from real customers. You later go back and clean it up, based on the growing confidence in the permanence of that feature.