Although a nice article I can honestly say that hiding the fact that a piece of code "requires" refactoring is not the best advice to give.
First of all, a developer will ALWAYS be short on time. If it is an on-going project the developer will always be asked to develop new functionality and I don't think there will be many managers paying a developer to rewrite what he/she should have written in the first place. As such the dev will always have to "inflate your estimates to help correct the mistakes of the past".
Secondly, code evolves. The term "refactor" in today's world means simply modifying the code to accomodate a new feature, which, in the vast majority of the cases, wasn't thought of when the code was written. And IMHO this is a perfectly normal process in development. A developer no longer writes a piece of code that our grandchildren will inherit and have to maintain.
If you define the term "refactoring" as fixing a problem in the code, then I think that is called bug fixing and not refactoring.
Or if you think of "refactoring" as a means to replace and code that you identified as written less optimised, than I don't think that is a thing for the client/manager to understand and pay.
Just my thoughts. ;)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.