Refactoring Not a Substitute for Design

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'.

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.

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.

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?

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.