Refactoring Not a Substitute for Design

Posted by Chris Sims on Feb 09, 2009

Sections

Process & Practices

Topics

Agile Techniques ,

Agile

Tags

TDD ,

Design Guideline

A member of the stack overflow community asked "Is design now a subset of refactoring?" The question highlights a common misunderstanding about the agile approach to emergent design. A common agile mantra is: "Test. Code. Refactor. Repeat!" This approach doesn't replace design; it simply spreads the work out over the life of the project.

Phil H. put his question this way:

The New Way seems to be to dive in and write what you need to achieve the first iteration of scope objectives, and refactor as necessary to have elegant solutions. Your codebase grows incrementally, and never has a big planning/hierarchical design stage. That, to me, suggests that software design (worthy though it is) has been subsumed into refactoring, because that's where the elegant code comes from, not the incremental additions to functionality.

Am I wrong?

Big Design Up Front is not design; it is just one way to accomplish design. Agile practitioners tend to prefer a different approach, in which the current design emerges in response to the actual functionality being supported. The design reacts and adapts to the needs of the system, which itself is constantly evolving and adapting to the needs of the customers.

An agile, test driven, approach to adding functionality and evolving the design of a system can be expressed this way.

• Create a test for the new functionality.
• Run the test and watch it fail, because the functionality hasn't been coded up yet.
• Write just enough code to implement the needed functionality.
• Run the test and see it pass.
• Refactor the code until the system, including the newly added code, is elegant.

The essence of this approach is to have a design that supports the functionality that we know we need, without being burdened to support those things that we think we might need someday (maybe).

Fabian Steeg referred to Kent Beck, and put it this way:

The goal is clean code that works. [...] First we'll solve the "that works" part of the problem. Then we'll solve the "clean code" part. This is the opposite of architecture-driven development, where you solve "clean code" first, then scramble around trying to integrate into the design the things you learn as you solve the "that works" problem.

It is possible to misinterpret this too literally. One participant gave this example:

The reason I make many design decisions early in the process rather than mid flow is this can often be the cheapest time to do so. For example, if we start writing an application using platform dependent technology early on, it may be a very expensive decision to reverse. If we take time to consider the platforms we want to support before starting to code, it is much cheaper.

This individual has fallen into the trap of misinterpreting 'emergent design' to mean that agile developers do no thinking up front. The current design should incorporate all of the information that we currently know. If we know that we will need to support multiple platforms, we include that in our design. However, if we are confident that we only need to support a single platform, then we will avoid constricting our design because 'someday we might want to port it'.

Some of the agile guiding principles are:

• You ain't gonna need it
• No functionality added early
• Optimize last
• Maximize work not done

It is worth noting that these are guiding principles, not rules intended to be followed mindlessly or dogmatically. They are there to help skilled developers make decisions, not to tell the developers which decisions to make.

What is your approach to design? How do you create an architecture that serves your code, and coders, without unnecessarily constraining them? Leave a comment and share.

1. Back to top

   Framework driven development

   by Dhirendra Negi

   Framework driven development could be answer to worries in Agile development where nobody writes code out of framework. You only need to refactor the framework if it fails to deliver certain functionality. Good,handsome code, Once written can easily be part of any refactored framework.

   Reply

2. Back to top

   When exactly am I making BDUP and when am I not?

   by Guilherme Lopes

   Suppose I am building a product and I can see the big picture of it. A web page creator for example.
   
   I start it with what I believe that delivers the most value, a simple web page creator that brings two blank fields, one for page title and one for text body.
   
   But I know that users will need to insert more texts and pictures and even change their positions, it's a web page creator after all. These changes can affect completely my software architecture, interface and database.
   
   What should I do?
   
   Start creating upfront an efficiently architecture for the big picture?
   Or just do the code that will accomplish my iteration tasks, regardless those issues already known for the next few iterations?

   Reply

• Older >