Channels ▼
RSS

15 Design Tips


Software Development's Agile Modeling Newsletter Jan. 2004

Welcome to Software Development magazine's Agile Modeling newsletter. This monthly e-mail newsletter is a free service for Software Development and SD Online subscribers. If you do not wish to get this newsletter, please follow the unsubscribe directions at the bottom of this message.

I'd like to share several concepts that I believe are important for agile design:

1. Agile designs are emergent; they're not defined up-front.
Your overall system design will emerge over time, evolving to fulfill new requirements and take advantage of new technologies as appropriate. Although you'll often do some modeling at the very beginning of a project during "cycle 0," this will be just enough to get your team going. Agile practitioners don't need to get a fully documented set of models in place before beginning coding.

2. Design models need to be just barely good enough.
You don't need to model every single detail, they don't need to be perfect, and they certainly don't need to be complete. Remember the last time you coded from a design spec (if you ever did)? Did you really look at all the fine-grained details? No, because you were competent enough to handle the details yourself.

3. Multiple models.
Effective developers realize that each type of model has its strengths and weaknesses; therefore they need to apply the right model(s) for the job at hand. Because software development is complex, you quickly realize that you need to know about a wide range of models in order to be effective. All of the models mentioned in this newsletter, and more, are described at the Agile Models Distilled page:
http://www.agilemodeling.com/artifacts/

4. You typically need only a subset of the models.
Although there are many modeling techniques available to you, any given project team will require only a subset of these. Think of it like this: In your toolbox at home, you have a wide array of screwdrivers, wrenches, pliers, and so on. For any given repair job you'll use only a few of the tools. Different jobs, different tools. You never need all of your tools at once, but over time you'll use them in a variety of ways.

5. Each model can be used for a variety of purposes.
A UML class diagram can be used to depict a high-level domain model or a low-level design, not to mention things in between. Use cases can be used to model the essential nature of a process or the detailed system usage description that takes into account architectural decisions. Never underestimate how flexible you can be with models.

6. Agile implementation techniques often enable you to do less detailed design modeling. Implementation techniques such as Test-Driven Development (TDD), refactoring and database refactoring are complementary to an Agile Model-Driven Development (AMDD) approach. With TDD, you think through the details before writing new code; with refactoring, you keep your object design of high quality; and with database refactoring, you improve your database schema quality over time.

7. Designers should also code.
Whenever a model is handed over to someone else to code, there is significant danger that the programmer won't understand the model, will miss some of its nuances, or may even ignore it completely in favor of his own approach. Furthermore, even when hand-offs are successful, you'll discover that you need far more details in your models than if you'd simply coded it yourself. In short, separating design from programming is a risky and expensive proposition. It's far more effective to have generalizing specialists on your team who can both design and code.

8. Prove it with code.
Never assume your design works; instead, obtain concrete feedback by writing code to determine that it does in fact work.

9. Feedback is your friend.
Never forget that you're a mere mortal just like everyone else on your team. Expect to receive feedback -- and actively seek it -- about your work, and be prepared to consider it and act accordingly. Not only will your system be the better for it, you'll probably learn something in the process.

10. Sometimes the simplest tool is a complex CASE tool.
When it comes to requirements, I prefer inclusive tools such as paper and whiteboards, but when it comes to design, I tend to lean toward sophisticated tools that (re)generate code for me.

11. Iterate, iterate, iterate.
With an iterative approach to development, you work a bit on requirements, do a bit of analysis, a bit of design, some coding, some testing, and iterate between these activities as needed. You also iterate back and forth between working on various artifacts, working on the right artifact at the right time.

12. Design is so important you should do it every day.
It's critical to think through how you're going to build something, to actually design it, before you build it. Your design efforts may take on the form of a sketch on a whiteboard, a detailed model created with a sophisticated modeling tool or a simple test that you write before you write business code. Agile developers realize that design is so important that they do it every day, that design isn't just a phase that you do early in the project before getting to the "real work" of writing the source code.

13. Design for your implementation environment judiciously.
Take advantage of features of your implementation environment, but be smart about it. Trade-offs are normal, but understand the implications and manage the risks involved. Every time you take advantage of a unique performance enhancement in a product (such as a database, operating system or middleware tool), you're probably coupling your system to that product and thus reducing its portability. To minimize the impact of your implementation environment on your systems, you can layer your software and wrap specific features to make them appear general to their users.

14. Document complicated things.
If it's complicated, document it thoroughly. Better yet, invest the time to design it so it's simple. Remember the AM practice Create Simple Content.

15. Don't over-document.
You need to document your design, but you shouldn't over-document, either. Remember, users pay you to build systems, not to document them. There's a fine line between under-documenting and over-documenting, and only through experience are you able to find it.

This newsletter has been modified from my forthcoming book The Object Primer 3rd Edition: Agile Model Driven Development with UML 2(Cambridge University Press, March 2004).


HOT LINKS:

The Agile Alliance home page is the best starting point for anyone interested in learning more about agile software development.
http://www.agilealliance.org

With Agile Model Driven Development (AMDD), you create models that are just barely good enough to drive your implementation efforts. http://www.agilemodeling.com/essays/amdd.htm

Check out the Agile Modeling mailing list at
http://www.agilemodeling.com/feedback.htm

Get agile modeling training resources at
http://www.agilemodeling.com/training.htm

"Agile Models Distilled: Potential Artifacts for Agile Modeling" provides links to pages overviewing various modeling artifacts, including inclusive ones that business stakeholders can easily learn.
http://www.agilemodeling.com/artifacts/

To learn more about database refactoring, visit
http://www.agiledata.org/essays/databaseRefactoring.html

Martin Fowler's refactoring home page is the best place to start when looking for refactoring-related information.
http://www.refactoring.com

Want to know more about Test-Driven Development (TDD)? Go to
http://www.agiledata.org/essays/tdd.html


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video