Refactoring

Some people may disagree however I believe that if you read Is Design Dead? and Refactoring with Martin Fowler the fair reader should get the idea that Martin Fowler supports some upfront design.

The absence of some design thought up front and lack of visible design effort before refactoring is that the programming effort may be just adhoc coding and rework rather than directed refactoring. The mitigating practice in XP is pair programming. But what about those not doing XP?

Any in-depth discussion about interface contracts, abstraction and encapsulation, Liskov and open-closed principles, state and invariants with regard to elements of design can be more than a little surreal. These are fundamental object-oriented design principles that some post-modern developers choose to ignore based on their understanding of Agile development.

Martin Fowler and Kent Beck allow for top-down, architectural refactorings in addition to smaller, finer-grained bottom-up refactorings. Most of the smaller refactorings can go either way while the bigger refactorings have bigger cost-benefit tradeoffs.

Baby steps do not always cut it.

Refactoring, Chapter 12: Big Refactorings (from Amazon summary):

Kent Beck co-wrote this chapter with Mr. Fowler. They discuss what they call the 4 Big Refactorings: Tease Apart Inheritance, Convert Procedural Design to Objects, Separate Domain from Presentation, and Extract Hierarchy. These refactorings are of a more all-encompassing type than the smaller individual refactorings from the preceding chapters. The co-authors do a great job at putting in a nutshell what would normally take very long explanations.

The problem with taking only baby steps during refactoring is getting stuck in a local minimum within the phase space of possible designs and having no way of getting out. The question in reality is to ask when the Big Refactorings turn into simply a code rewrite.