text: I have written software for development projects for 30 years and I have managed several projects. Martin Fowler has extraordinary insight, and I enjoy reading his papers for the gems of thought I find. 
  
  The main lesson I pick up from this book is: Break your large project into projects sufficiently small that you can sensibly abandon Refactoring for each of the small projects.
  
  Refactoring works well in some cases, I suppose. Refactoring works well for some people, I suppose. I'm skeptical, though. Fowler filled the book with page after page of the detailed Refactoring method applied to a problem he acknowledged as too simple for application of Refactoring. He assures us that Refactoring may overload small projects with methodology, making it unsuitable for them, and it works really well for larger projects. I suspect, however, that the burden it imposes enlarges as the job enlarges. Fowler gives me no good reason to think otherwise. If I'm to risk this methodology on a large project, I want to see it perform well on a smaller project first.
  
  Fowler conceives methodologies that attract zealous disciples. In the case of Refactoring, the methodology may succeed for its attractiveness rather than for its practical utility
  