Every day, in every way »
I’ve watched the meaning of the word “refactoring” drift over the past several years. I don’t know if this is specific to the Ruby community or a larger problem in the software industry. But on nearly every project I’ve been on, I’ve heard statements like this in iteration planning meetings:
Oh, this feature is going to touch the Frotz class. We’ll need to add some time to the estimation. The Frotz class is a huge mess, we really need to schedule time to refactor it.
Nearly every project has had areas which everyone recognized as painful. In fact, everyone had been recognizing those areas as painful for weeks or months. If there’s an area of the code that everyone has recognized as painful for weeks, the time for refactoring has been and gone. […]
I’ve only been on one software project, but Avdi Grimm’s piece already really rings true to me. This distinction between refactoring and cleaning up that scary class of which everyone is ashamed is incredibly useful, especially for product to be able to see the process clearly instead of being impatient and intimidated. As I’ve learned throughout the last year, in software development (and everything else?), perception is paramount.
