Agile Modeling

RickHigh writes: "I've been waiting for a book like this. If you are doing software development of any kind, you should read this book. Especially if you are doing Extreme Programming and you errantly believe modeling has no place in XP. Or, your doing the Unified Process and you feel that your models and documents are more important than a working system, or you feel you are bogged down in documentation and required artifacts (more likely). Agile Modeling (AM) is a modeling methodology that enhances your modeling endeavors, whatever your process methodology inclination. Agile modeling will help you effectively incorporate modeling into your organization." Read the rest of Rick's review below. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process author Scott Ambler pages 400 publisher Wiley, John & Sons, Incorporated rating 7.5 reviewer RickHigh ISBN 0471202827 summary A worthwhile melding of XP techniques with modeling of general interest to programmers of all stripes.

The title is only partially accurate as the book covers a lot more than modeling. I know from experience that picking titles is tricky (you can't please everyone). You don't need to be a UML expert to get value of this book. Any software developer should be able to appreciate it. Modelers, software developers and Yes, managers will find this material useful. In fact you may want to buy a copy and put it on your manager's desk. This book is original and well thought out. It is also well written and very readable. I wish there were more examples of applying the different artifacts in different phases of the XP life-cycle, but there has to be room for the next edition. The depth is appropriate.

Many UP developers (and those working with other prescriptive processes) get bogged down in the tonnage of documents and artifacts that are required. They wonder if they are ever going to have time to actually write the code.

XP offers a methodology for building high quality software fast. However, many XP developers, and I've spoken to them about this very subject on many occasions, find that XP does include time to do models. This books shows how to integrate XP and modeling.

This book sets the record straight about design and Extreme Programming. Actually, Kent Beck set the record straight with the first book on XP when he said 'In the time it would take you to code one design, you can compare and contrast three designs with pictures.' Kent Beck's views were corrupted over the years for various reasons that Agile Modeling explains, as it clarifies once and for all the relationship between XP and modeling.

The book emphasizes that you should model to understand the problems and only apply the right artifacts, i.e., that not all modeling must lead to writing code.

Despite the title, he AM book transcends just being a book on modeling; the book covers many aspects of developing software. Agile Modeling endeavors to be real. By real I mean it talks about real issues and how things are handled in the real world, not the perfect world covered by most books. For example, the chapter on documentation is an excellent coverage of the subject, but not idealized beyond all usefulness.

Like the original XP book, the AM book lists values, core principles and practices. It also adds supplementary principles like 'Content Is More Important Than Representation.' A key lesson from the book is that models are important if they help you understand and solve problems. And, models do not have to be perfect -- in fact they can be thrown away when you are done with them. After all is said and done, 'Software is your Primary Goal.'

The author, Scott Ambler is the author of numerous books (and by numerous I mean a lot) for the Unified Process, and UML. He also contributed to the Mastering EJB Book, and the Java Elements of Style book. All his work in UP seems strange since AM seems to have closer ties to XP than UP, but that is probably my own warped misconceptions of the world. Bottom line, Scott has mastered the craft of writing and I really enjoyed his writing style. The first few chapters seemed a little slow, probably because their content has been covered before in other books. The chapters on AM and XP, though, were informative and useful (as was the chapter on agile documentation mentioned earlier).

If you are doing software development of any kind, you should read this book. It is an informative and enjoyable read.

What's covered? Here are the chapter headings:

• Table of Contents:
• PART I: INTRODUCTION TO AGILE MODELING.
  • Introduction.
  • Agile Modeling Values.
  • Core Principles.
  • Supplementary Principles.
  • Core Practices.
  • Supplementary Practices.
  • Order from Chaos: How the AM Practices Fit Together.
• PART II: AGILE MODELING IN PRACTICE.
  • Communication.
  • Nurturing an Agile Culture.
  • Using the Simplest Tools Possible?
  • Agile Work Areas.
  • Agile Modeling Teams.
  • Agile Modeling Sessions.
  • Agile Documentation.
  • The UML and Beyond.
• PART III: AGILE MODELING AND eXTREME PROGRAMMING (XP)
  • Setting the Record Straight.
  • Agile Modeling and eXtreme Programming.
  • Agile Modeling Throughout the XP Lifecycle.
  • Modeling During the XP Exploration Phase.
  • Modeling During an XP Iteration: Searching for Items.
  • Modeling During an XP Iteration: Totaling an Order.
• PART IV: AGILE MODELING AND THE UNIFIED PROCESS.
  • Agile Modeling and the Unified Process.
  • Agile Modeling Throughout the Unified Process Lifecycle.
  • Agile Business Modeling.
  • Agile Requirements.
  • Agile Analysis and Design.
  • Agile Infrastructure Management.
  • Adopting AM on an UP Project.
• PART V: LOOKING AHEAD.
  • Adopting Agile Modeling or Overcoming Adversity.
  • Conclusion: Choose to Succeed.
  • Glossary of Definitions and Abbreviations.
  • References and Suggested Reading.
• Appendix A: Modeling Techniques.

Sites of interest

• The Agile Modeling site
• The XP programming site
• The Agile Alliance site
• Scott Amblers Website
• Applying XP to J2EE

You can purchase Agile Modeling from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Comments

Many programmers do this anyway.

[abigor]

OK, I guess I'm mostly speaking for myself and those programmers I work with, but I think many programmers have, over the years, evolved a personal set of design and modeling techniques that closely resemble what's described here. Using the unified process from the start just doesn't work for me, because it's not the way I think. I do a combination of "loose" modeling with UML, rapid prototyping to work out thorny problems, and then a complete design review to fix up the problem areas. Then repeat. Eventually, what emerges is reasonable for the time spent.

For me, XP techniques come in handy for rapid prototyping, especially the flow of ideas that come with working closely with another programmer. And the UP is good for bringing elegance to the overall design.

Finally, let's not forget the ultimate design tool for every programmer: the whiteboard. Ah, the smell of erasable marker in the morning...

Re:I was just reading this at the bookstore...

[phallen]

While it is true that lightweight/Agile methodologies such as XP are based on the idea that communication is key, but there is another core value: discipline! There are many principles that any programer can use to improve their productivity, if your are disciplined enought to do them without a team of people keeping you honost. Here's a list of techniques I use as an XP guy when I'm working by myself:

Test-First Programming: write some unit tests before your write the code they test. Then write the actual code and work on it until the tests pass; go back and write more tests. BTW: if you are saying "test-first programming doesn't work!" then you've never tried it, right? Tell me if I'm wrong.

Itterative Development/Refactoring: always re-evaluate your code and look to make it better, easier to read and understand, and more modular. Develope in small steps that produce a working system quickly and often, even if the system doesn't do much at first. Big-bang development = Big-bomb development.

Implement the simplest solution that will work: don't overengineer the system when you don't need to, even if you have some cool, but complicated, ideas. If you need a more elaberate solutions later, refactor it in.

Deliver the most value-producing code first: give the users the thing they need the most first. Don't work on the coolest part of the system first unless it's the most valuable.

Like I said, anyone can do these things if they are disciplined enough to do them, and you don't need a pair/team to do them, though it's easier.

Itterative Development/Refactoring

[swagr]

I use IntelliJ IDEA which has insane refactoring. (I'm using the Early access preview which is even better that 2.5.2).
As some book I read put it, "refactor ruthlessly". I do. I think that's my one saving grace.

My biggest problem is that I over-engineer. Quite often I end up with a bunch of interfaces, abstract classes and implementations, where, in hindsight, something really simple would have worked just as well.

Or I end up "bending over backwards" to create more re-usable objects that are never re-used.

Object Oriented Overkill is my problem.

Re:slashdot have special interest in good reviews

[GuyMannDude]

It doesn't personally offend me as much as it does you (some could argue that slashdot has the right to get some credit for referring interested readers to the book) but I realize a lot of people feel a little red flag go up inside their heads when they see something like this. Personally, I don't see why the BN link couldn't be replaced to a search-engine query at pricescan.com or AskJeeves or something like that. With a click on a single link, slashdotters can compare prices at numerous bookstores. Hell, why not just a google search box with some choice keywords already filled in. Click on the search button and it automatically does a google search on "price Agile Modeling Effective Practices Extreme Programming Unified Process"? That way slashdot wouldn't face any criticism for getting referral points.

GMD

An alternative source for the book

[Ankh]

You can buy this book at Wiley (the publisher's site), and it's likely that the author will get more royalties. (in theory my contract gives me a higher percentage for direct sales, although it's unlikely my XML books would ever sell enough to get me royalties)

Liam Quin

PSP is SO lame

[epictetus]

I started reading PSP a few years ago and found it just completely ridiculous. You're supposed to track how long it takes yourself to write common programming structures, like for() loops, and then eventually you will have a cookbook of all the common programming structures. You use this cookbook to estimate how long a project will take you (Ah, to implement this, I will have to write 3 for() loops and a switch() statement! That's a total of four hours!). After several months of gathering and analysing the data, you'll be able to estimate project time to the minute and also track your improvement.

If you are designing your code down to this level of detail, then you are finished before you start typing it. The process seems to think that programmer time is taken up by mechanical, predictable tasks. This may have been true in the days of punch cards. In modern times, all the time-consuming work is mental, and you won't know how long that takes until you've done it. Sure you can still roughly estimate how long things will take, but tracking how long it takes to write a for() loop is no help at all.

Modeling

[PinglePongle]

Some people have asked what this modeling thing is all about; as a public service, here's the PinglePongle version.

Some academics regard the process of building software as a descent from the abstract to the concrete. Typically, it starts of with "hey, we need a thingumajig - it must streamline our widget creation process". This is usually followed up by a requirements spec which says what the thingumajig should do, but doesn't go into how should be constructed.
The next phase typically involves the developers working out how to build a thingumajig which meets the requirements spec.
Once the developers have worked out how to build the thingumajig, they start to code it; if you're lucky it gets tested and eventually it's released.

All these phases do occur, but the way in which they're executed varies enormously. Frequently, they overlap; frequently people move back and forth between the phases several times; frequently it's hard to tell which phase you're in.

Modelling general concerns mainly the "how do we build a thingumajig" design stage. A model can be anything that helps to convey the intention of the design without being actual code - a crayon drawing, a piece of prose, an email, a memo, a flowchart, a wall-sized database diagram, a haiku. There are a bunch of methodologies which adress the modeling phase, most famously the Unified Modeling Language (UML) which defines a standard vocabulary for object oriented design using around a dozen different diagram styles.

The problem with models is that they can become very cumbersome and end up leading a life of their own (here's a previous /. thread...), and it's not uncommon to have projects with many times more paper than code.

As it goes, I believe that anyone who takes programming seriously should be at least passingly familiar with the most common modelling practices - UML use cases and class diagrams, database E/R diagrams, flowcharts; in my projects I ask the developers to model the tricky parts of the project, but only with the explicit purpose of understanding the problem better before starting to write code. You can change a model around easily and quickly - changing a class diagram to put a method in a different class takes seconds - but if you realize halfway through coding there's a better way to do it, you almost never have time to fix it.

I've ordered the book (no, I'm not going to tell you where from) - and if it's as good as Cockburn's other work, it'll be money well spent, even from bn.com !