Hi Syed,

I know that this response may seem difficult and hard to follow, and probably may seem impossible to apply in many circumstances, but sometimes there are more opportunities than it seems.

About cleanup, I often say, just as product has nothing to say when we talk about whether to use a for loop or a while loop, neither does it when we decide whether to clean up or not. Moreover, it is the developer's duty to know when it's time to clean up. And if you notice, it's the developer who decides when the feature is complete, not the product team. Sadly, generally, developers decide to stop development as soon as they have a working prototype, and the product team just accepts that it's finished when the developer says it's finished, even if it took longer than expected. Furthermore, even if you make estimates, it's the developers who set the times. Therefore, it's in the developers hands to decide when to deliver, and so, they can comfortably do cleanup before starting and before delivering.

So, just try that, a little cleanup before and after.

I have some resources explaining my experiences or even techniques:

- How I Fixed 1,000 Bugs In Six Months Without Stopping Delivery: I directly disobey business and I did a refactor, and I became the hero, because that was what they wanted (yet, they thought otherwise in the beggining)

- Deliver Anything On Time!: I explain how to satisfy any deadline, even the shortest ones, if you do not have problems delivering crappy code.

- The Emotional and Technical Guide to Rescue Stalled Software: Because I know that it is difficult to face this, so, a "small" guide to clean up bad code

- Refactor Lessons Learned From The Bowling Game Kata (1/2) (and part 2): a guide with ideas to enable refactors in a very small steps.

The idea is not doing great refactors, instead small continuous cleanup.

So, I hope it helped!