It’s your job to have well-written, refactored source code. You’re succeeding at it, and that’s great.

It’s also your job to deliver on time. If you want a motivation to stop obsessing about code quality, how about the fact that if you spend precious time doing changes on code which is already correct, fulfills the requirements and works as expected, you wan’t be able to met the deadlines for other requested features, thus not doing the job you’re paid for?

@bmused, I know your pain all too well. Much of it for me stems from stunning WTF code I’ve had to deal with in various places. It’s professionally embarrassing to foist crap on others. There are even 2 times I recall begging the team lead to refuse to allow some code into the system. Oh well; ultimately delivery trumps quality even when code is acknowledged as bad. The code we all have to deal with proves it.

Motivations

• A good Scout always leaves his camp site better than he found it. Amen.
• It’s still better than the existing horror.
• Fun. Good design makes coding easier and more fun.
• Avoiding pain, both self and boss inflicted. I simply learned to let good enough be. That was hard, and I must always be on my guard on this.
• A “continuous improvement attitude” allowed me to not worry so much up front.

Good, thoughtful, complete, design up front is extremely important. Don’t try to be too smart for your (and our) own good. I’m not saying “elegant”, “brilliant”, “slick implementation of obscure language features”, etc. I’m saying complete, straight forward, Object Oriented. Fight for the time to make a decent design prior to coding.

A good design naturally lends itself to “good enough” coding that lets you sleep at night. You Code Complete (a play on a must have book title) so you simply don’t worry so much about inventing places for future extension. And being “complete” there’s less urge to keep fussing with it.

I had 2 very different experiences w/ the same code base. The well designed one more than anything completely defined business domain classes to cover the requirements; it was criticized by PEBCAK OO-ignorant co-workers for “too much”, “too busy” – but it coded easier and faster (you may be surprised how much time you seem to have for improvements during coding!), and sailed through testing in days. Compared to the other time where design was incompetent at best and we were stuck in a 3 month test-fail-hack cycle of hell. Imagine how you might feel about getting it absolutely perfect next time given these two experiences.

Continuous improvement is a happier place. Get your new code good enough and as opportunities present themselves make improvements.

• One’s code base is either getting worse or getting better; continuous improvement or bust.
• Making improvements later, in the face of known changing requirements, or just time to have thought about it is much preferable to second guessing every potential future change up front.
• Consciously prevents over engineering in anticipation of changes that never come – my pet peeve is the interface implemented by only one class. An innocent thing you’d think but I see it way too many times and IMHO in a large code base every pointless, unhelpful bit is painful.

Good refactoring practices along with unit tests is the way to implement continuous improvement. I very highly recommend Refactoring by Martin Fowler.

There is some merit to working on what we call technical debt on an ongoing basis. Keeping your code clean keeps the system agile and maintainable. But you have to strike a balance; on the one hand, you don’t want the system design to drift so much that the software becomes unmaintainable, but on the other hand, you don’t want to be “gold-plating” for marginal benefit, and missing your deadlines.

Seth Godin says it this way: your job is to ship. The way you do that on time and on budget is, when you run out of money or you run out of time, you ship. You should plan your work so that you don’t run out of either.

Seth discusses this in more detail in his Ted Talk, here:
http://vimeo.com/5895898

Yes, I find myself faced with this when designing much more so than when developing. If I can’t think of an elegant solution I tend to move on wherever possible and let my subconscious do the hard work for me – this avoids procrastinating.

At the end of the day you need to remember that you want to finish the system (presumably) and as such you just need to tell yourself to move past to reach your end goal.

Consider the amount of time used to solve the problem to be one of the costs you’re trying to minimize. You won’t be able to optimize this perfectly, so just use your best judgement.

Perfectly elegant solutions that take way too long and horribly ugly kludges are both failure modes. Try to maximize elegance per unit time, not straight elegance.

Also, there’s a good principle called YAGNI: You Ain’t Gonna Need It. I think it’s slightly overhyped, to the point where some people think it’s an excuse to never plan for the future, but more often than not, it applies. If you put something in your software that never gets used, that’s not elegant, even if it would have been a good solution to a problem that never shows up.

I think you will find worse is better to be good reading. It’s an attempt to explain the failure of LISP machines to LISP hackers and the details are ancient history by now, but the details aren’t the important part.