That's the best strategy. The most bug-free code is the one that wasn't written in the first place, therefore I refuse to write code unless absolutely necessary :).
Not to mention the best one for code coverage. When junior devs ask me for advice regarding increasing code coverage, I tell them instead of writing more tests, how about writing less code? Our boss really liked that one.
Unfortunately, I've seen IT departments taking this joke as an axiom. It seems common in schools and universities, where the infrastructure is maintained by being so limited as to be completely useless - and hence unused, and thus without problems caused by users...
One of my favorite tricks, that I sometimes play on myself:
Insist the person documents all the quirks and gotchas in a block of code or library. Sometimes the embarrassment at having to justify it will prompt them to fix the problem, other times they (or I) will realize that it literally takes less time to fix the issue than it does to apologize for it.
Something about the writing process unearths simpler solutions to tricky sounding problems. Possibly the same phenomenon that TDD tries to exploit.
Yeah absolutely. I always reduced this to "three months" and passed the phrase around to juniors, etc. And when I interviewed at the last company I worked for, the CEO specifically said, "If you aren't horrified by something you wrote three months ago..." And that's when I knew I wanted to work there (among many other reasons, of course).
I would worry that this would encourage more tech debt than I'm comfortable with. I already struggle with people shrugging off obviously predictable consequences of their thoughtlessness. I kind of expect people to at least attempt to think three months out. Who knows what we'll be doing in six but cmon.
Do you really look at code you wrote three months ago -- or any code you've just written -- and not see a lot of things you could improve? This isn't about not having foresight or failing to plan or not designing well.
Every time I am about to do a commit, I look at the code and give myself fifteen minutes to make it better. Always have (probably a habit I learned doing homework in college? I'm not quite sure).
In the grand scheme of things you'd hardly notice that it takes me a little bit longer. Over time those improvements become habituated and I just do a lot of them while I'm coding. Especially when I get stuck.
It's not in like cleaning while you cook. Once you have a tempo it hardly takes any longer to prepare the food but you don't leave yourself with a mess that discourages you from doing it again.
You seem to be implying that you only ever need fifteen minutes after any programming task to make all possible improvements that could ever happen to that code.
Sometimes, of course, you write code that is just right, and it still is after a year.
But, yes, that "What-was-I-Thinking" moment happens on a fairly regular basis. ;-)