次の方法で共有

Motley says: "Refactoring means no more up-front design"

  • [アーティクル]

Summary

 

Motley:  Refactoring keeps my design clean from the start, so no more up-front design!

 

Maven: Up-front design is still necessary to achieve clarity on the overall approach (preventing rework later) and needs to be documented to allow others to review your thinking.

______________________________

 

[Context:  Motley is trying to educating himself on agile development and is reflecting on some reading with Maven]

 

Motley: This is really cool - I've been doing some reading on agile development and because I am doing refactoring continuously, that means I can do away with all that up-front design stuff we used to do.

 

Maven: Do away with it? Hardly! Maybe for a small couple-hundred line program, but any bigger than that, there is still value in thinking through the problem before you code anything - at least, if you want to prevent major rework later in the cycle when mistakes are more costly to fix.

 

Motley: But refactoring is going to keep my design clean. What's the point of all the up-front thinking?

 

Maven: That's true - refactoring helps you continuously keep quality high. However, if you make an investment in a bad high-level design and architecture, it becomes extremely hard to refactor yourself out of it. Then you are talking about reengineering, which can be a huge task. Refactoring is for small design changes without changing external functionality. Large changes are not as well suited to refactoring as it may lead to drastically changing the way requirements are implemented.

 

Motley: But I want my design to emerge based on the learning I get while coding!

 

Maven: You want the details to emerge, but you need clarity on the overall approach before you flesh out the detail. A design phase is needed to understand the problem, investigate various high-level solutions and their trade-offs, and document your overall approach.

 

Motley: I'm not sure I buy that - the agile manifesto states that we should favor "working software over comprehensive documentation." No design document needed!

 

Maven: Not exactly. You stated the keyword: favor. It does not say there is no need for documentation whatsoever. We need that documentation to keep the stakeholders in our design happy and to provide something concrete for people to review.

 

Motley: And I thought I was done with 100 page design documents…

 

Maven: You are! You want to document "just enough" in your design. Documents of 100 pages in length are generally overkill and violate the lean principles we talked about previously.

 

Motley: But how do I know what is "just enough"? If I have 3 days on my schedule for design, "just enough" usually just means I hit the end of day 3.

 

Maven: Let's save that for another conversation. I have a great way to measure "just enough", but I am going to leave you in suspense.

 

Motley: Fine. I don't want to be here all day anyway. 

 

Maven: Of course, the other topic of interest is once you have "just enough", you want your design to be "good".

 

Motley: Great. I want "just enough" - I have no idea what that really means - and I want it to be "good" - I have no idea what that really means either. Judging "good" on a design is all in the eye of the beholder.

 

Maven: You're comparing judging a design for "goodness" to judging looks?? Hah. Fortunately, we can get a little more scientific than that and focus on the principles that generally make one design better than another. Let's do that...

______________________________

 

Maven's Pointer: Be careful with the term "emergent design". Many developers equate the phrase "emergent" design with jumping into Visual Studio and coding. What "emerges" at the end is some kind of design (usually junk). Truly "emergent design" uses a feedback technique to provide you continuous confirmation that you have a clean and working design. An example of an emergent design technique is test-driven development (TDD). Tests drive your design, refactoring keeps it clean, and test automation validates it all works.

 

Maven's Resources:  Agile Development Manifesto, Wikipedia entry on Continuous Design

Comments

  • Anonymous
    July 11, 2007
    Good article. We need to remember that the design is not only to be able to formalize to the solution, but also to communicate to other team members. And, documentation can come in many forms, not just paper. wiki's, white boards, pictures of white boards - any knowledge that is accessible. Just enough. Keep on the good work!

  • Anonymous
    July 16, 2007
    Great comment, Gil! One major reason to do design is for others to review your thinking (i.e. communicate with team members). It's not important that it be a big formal document. A Microsoft, we use wikis to do design and review designs, shared OneNote notebooks, brainstorming sessions on whiteboards captured by digital camera, LiveMeeting sessions, and the like.