Is Refactoring a Necessary Waste?

In this article I found an interesting definition: necessary waste, which is qualified as "the best way we currently know how to do a job even if it does not have a customer value". Following this line Amr Elssamadisy says that refactoring - a necessary waste - is not valuable to the customer and that you should only "refactor code that no longer meets the requirements of the user".

I strongly disagree with Amr for a bunch of reasons.

The first and simplest of all is this one: refactoring eventually SAVES time, as once you'we written your software you AND many other people will have to read it. A complicated code thus implies more time needed to understand it, and probably much more time to safely modify it. And guess who is going to pay for it? Saved time IS valuable to the customer, as it translates into considerable money savings.

Leaving aside all other reasons and considerations you can find in literature, I'll have to add this one: I love clean and elegant code, just as I liked clean and elegant mathematics expressions since when I was at school; I strongly agreed with my regretted maths teacher, who used to value more students who presented elegant solutions. Unaesthetic code simply disturbs me. I'm not saying all my code is elegant and perfect (I'd like to, but it would be a huge lie), but that's what I aim to when I'm coding. This is one of the reasons for which I've joined the anti-if campaign (I hear an English version will soon be available so stay tuned on the site).

One caveat: if you're working on a piece of code and find something else that smells don't switch your tasks, even if the refactoring is (looks) trivial: just pen it down and come back later. I find it a much better strategy, or at least it is for me - and for mr. Kent Beck:

We'll make a to-do list to remind us what we need to do, to keep us focused and to tell us when we are finished. ... When we finish an item, we'll cross it off.

(Quoted from Test-Driven Development: By Example)