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
