Drucker on Refactoring - no really! Here is what Peter Drucker might have had to say about refactoring were it available as a practice when he wrote these words in 1954.

"A favorite story at management meetings is that of the three stonecutters who were asked what they were doing. The first replied, 'I am making a living.' The second kept on hammering while he said, 'I am doing the best job of stonecutting in the entire country.' The third one looked up with a visionary gleam in his eyes and said, 'I am building a cathedral.'

The third man is, of course, the true 'manager.' The first man knows what he wants to get out of the work and manages to do so. He is likely to give a "fair day's work for a fair day's pay."

It is the second man who is a problem. Workmanship is essential; without it no business can flourish; in fact, an organization becomes demoralized if it does not demand of its members the most scrupulous workmanship they are capable of. But there is always a danger that the true workman, the true professional, will believe that he is accomplishing something when in effect he is just polishing stones or collecting footnotes. Workmanship must be encouraged in the business enterprise. But it must always be related to the needs of the whole.

... The tendency to make the craft or function an end in itself [in future] will therefore be even more marked than it is today. ... The new technology will need both the drive for excellence in workmanship and the consistent direction of managers at all levels toward the common goal."

What Drucker is telling us is that craft workmanship such as zealous refactoring is important both to an organization's morale - it is important that people can take pride in their work - but also to the quality of what is being produced. However, over-zealous refactoring destroys shareholder value. So beware of the cruft polisher on your team. Refactoring should be done for the right reasons - to eliminate technical debt, to rebalance the books, and facilitate future iterations. It should never be done simply because a developer doesn't like the architecture or the implementation. If you can't answer in the positive to this question - does this code prevent us from efficacious delivery of future functionality? - then any refactoring is to use Drucker's term merely "polishing stones."