Why Do Programmers Hate To Throw Away Code?

I just stumbled across The Joel Test. The Joel Test is an easy best practice pattern you can use to optimize your productivity. When I read Joel's article I immediately got a new insight into programming psychology.

Why do programmers hate to throw away code?

Like Joel says, programmers really tend to object to throwing away code. But how does this relate to the refactoring hype we've seen over the last few years? The point is, refactoring is probably done badly. Refactoring is all about throwing away old code, getting your new code to reflect new insights you got from problem domain analysis. Refactoring should be done thoroughly once a design problem is detected.

In Joel's opinion, writing specs helps to prevent refactoring. But what is a design spec if not code in an abstract high-level language. So changing the design is basically nothing but throwing away code - again.

Writing more specs leads to more documents that must be maintained in addition to the code. They get obsolete over time if they're not used on a daily basis. In my experience a lot of specs should be provided as comments in the code, or directly as code itself. Simply increasing the amount of specs produced will not achieve a better design. You need good developers who are able to design high quality code.

High quality code implements domain logic in a way that it can be read just like a spec.

Good programmers don't hate to throw away code - they are excited about throwing away code to achieve a better design.