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

I was just reading this at the bookstore...

[swagr]

My problem is that I'm working as an independant contractor. And many other people work on solo projects. Most of these systems (SCRUM, Extreme, etc.) are geared towards a group of developers. It's much harder when there's only one of you.

What about techniques/systems for the 1 man show?

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.

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

[Courageous]

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.

For me, what works so well about Test First Programming is that it strongly drives me. I have concrete goals, objective measurement, and even a built in reward system of sorts. When all else fails and I'm feeling particularly unmotivated, I write more test code, giving me more things to test.

C//

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

[david duncan scott]

My God, you asked this question and got answers, and not one reference to masturbation. Is our little Slashdot growing up?

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

[jdavidb]

I highly recommend the Personal Software Process from the Software Engineering Institute at CMU. PSP focuses on how you can improve your own process, which is fundamental no matter how many people you work with. I've been reading the two PSP intro books (one aimed at introductory programming students, one aimed at professionals) this year and have gotten a lot out of it. I'm looking forward to getting a lot of this implemented a little later this year. I don't work alone, but it's very close as we have very few people and projects rarely require more than one person.

Don't confuse PSP with the TSP also described on the site. TSP is aimed at teams. (And in some people's minds, PSP appears to exist only to support TSP.)

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

[frank_adrian314159]

What about techniques/systems for the 1 man show?

I presented a paper on this topic at last year's Conference on XP and Agile Methods. You can find a copy at ftp.ancar.org.

News for Nerds: An Holistic Approach

[tps12]

What is up with the headlines today? First it's "Affective Computing," followed by "Agile Modeling." Can we expect "Attentive Debugging" next?

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

bn.com? wtf?

[titonutz]

Everyone knows Amazon is better. Compare:

Price at bn.com: $27.99 (%20 off)
Price at amazon.com: $24.49 (%30 off)

Buy from amazon.com

CLH model

[avandesande]

we use the CLH model ... (code like hell!)

Pick the tasty tidbits

[Mr. Fred Smoothie]

What kind of system are you looking for?

Most of the prominent SD methodologies/philosophies are "geared toward teams" because it's axiomatic that the great problem of the successful organization of software projects is related to the challenge of effecively communicating compex requirements and designs between individuals.

Now, if you're the only programmer, presumably you don't need to communicate design at all -- aside from the spectre of the future mainetance programmer.

However, there are still other project stakeholders with whom you need to communicate; managers, users, etc. So, you can pick the bits of the other methodologies that deal with effective communication between developers and the other project stakeholders. For instance, use cases and working prototypes, or XP's "planning game" may be very useful tools to help you nail down the requirements or schedule deliverables.

The most important thing though (and as an adherent of the Agile philosophy, I'd say this goes for groups of developers of all sizes as well) is to pick the bits that work best for you. What works best w/ one customer may not work at all with another. Your best bet is to develop a toolset of techniques that have been successful for you before, and to keep an open mind about what the "best way" to do things is.

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:bn.com? wtf?

[Voytek]

or you could go to http://www.bookpool.com/.x/riiycqqu4m/sm/047120282 7 and get it for 21.50

Ok

[Mr_Perl]

I read this, and am still wondering what is modeling. Anybody?

Re:Ok

[Capt_Troy]

Design of software using models, that is, drawing class diagrams, use case diagrams etc... This class contains that and inherits from this and so on.

Re:Ok

[jamesmartinluther]

Modeling, as in other fields, is forming a simplified representation of reality which assists in the understanding of reality (and often modeling even distorts this understanding). In the world of software development, I would say that modeling is a conceptual architecture that can help developers organize the work.

When I'm modeling a new project, people will notice diagrams and other scribblings on my desk as I attempt to work out how all of the basic utilities, resources, and user interfaces of an application will work together.

Re:Ok

[Anonymous Crowhead]

I read this, and am still wondering what is modeling. Anybody?

[posted] by Mr_Perl

No wonder.

Re:Ok

[Mr_Perl]

Haha, ok that deserves a funny. 8)

The CQC-S System

[jamesmartinluther]

Caffeine
Quake
Code
Caffeine
Quake
Code
Slee p

Re:The CQC-S System

[PD]

He unrolled the loop.

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

No, don't buy it from amazon

[Jerf]

Don't buy it from Amazon. Hey, the boycott is still on. I'm honoring it. There's good news in the fight but it's not over yet.

Re:let me know

[sharkey]

Baby step: With a so-called "Centerfold".

BOOKPOOL RULES : $21.50 / 39% OFF

[cpfeifer]

Everyone knows Bookpool is the cheapest place in town.

Oh, good!

[epepke]

Another methodology with a catchy name that is supposed to fix all the problems with software development but never quite does. Just what the world needs.

Re:bn.com? wtf?

[cpfeifer]

Yup. But you could buy it from me with this link.

OT:
In an Amazon URL:

http://www.amazon.com/exec/obidos/ASIN/020171091 9/ ref=pd_gw_qpt_1/104-0173505-5464702

the element right after the ASIN is the "product id", everything after that is session tracking info.

Hah!

[avandesande]

even cheaper 20.99

http://www.bookvariety.com/BookDescrip.asp?ISBN= 04 71202827

Good ideas

[kaladorn]

you've got some good ideas, but let me point out that refactoring time is often lost to time pressure. Many times, code that is "okay" or "not so great" is sufficient (depends on environment, mind you - an Internet startup looking to get a product out versus a contract software house doing MilSpec stuff) and it is more important to get on to other things than it is to optimize and clean up. Of course, in the end, it bites you on the ass and then you have to do more painful refactoring.... but if you did it up front, you might not get to the later as your company runs out of VC....

I've also worked on complex enough systems that in order to get working even _basically_ you had to do a lot of work. Sometimes (and with some problems) there IS no convenient way to parcel it into smaller pieces and so you just have to bite the bullet, spend the time, and write the code that needs written to give you the smallest useful chunk. That can still be a fair size.

Examples I've run across that come to mind are some network related things that just don't do _anything_ till you get them right and that requires a certain minimum infrastructure.

Also, in some situations, the required effort to test jig a piece of code or to subdivide the task effectively doubles the amount of work required (or more) and thus isn't economically viable. For certain applications, the key tests are integration test results, NOT unit tests. Yes, you do leave yourself open to getting bit in the ass later... but it work a fair percentage of the time.

But, having raised those "real world" comments, I think the discipline proposed is an awesome idea!

Hear, hear

[Anonymous Brave Guy]

I have a fantastic manager, who equates "minimal change" with "minimal risk".

So we never refactor anything, and if we're working in an area of code to add some new feature, it's forbidden to fix any old and long-standing bugs while we're there, even if doing so requires negligible effort and all of the relevant code is going to be completely retested as a result of the other work anyway. Never rework a sound design into another sound design when a smaller hack to the original will do.

Sadly, I kid you not.

Re:Hear, hear

[scott1853]

I agree a little bit with the manager. But I can also see how in certain situations he could be wrong.

If you truly are completely restesting ALL the functionality, then by all means, bugs should be fixed. On the other hand, some piece of code in another module could be expecting buggy results from the piece of code that you think is simplistic to fix. So unless it's a bug in a self-contained routine, then fixing it may require more planning then "I have the source file open, so...".

Re:Hear, hear

[Anonymous Brave Guy]

The problem is, while I see the point of the "minimal change" doctrine, it can be taken to extremes. We are currently shipping what I deem to be crap, and needlessly so, because management is too anal about procedures and not enough about actually producing a quality product. (I'm not talking about bugs in core library routines used all over the place here, I'm talking about naff UI routines because someone was lazy, or a divide-by-zero that always goes off in the same place because it's not checked.)

By the way, since they shifted my old boss onto another assignment, I am now the only person even remotely qualified to assess how risky any such change would be. The manager concerned wouldn't know his way around the code -- or even the overall design -- if I gave him a detailed map. I wrote much of it, and have in the past extended or fixed much of the rest. Draw your own conclusions about whose assessment of risk is most likely to be correct...

Misconception

[rovingeyes]

"XP offers a methodology for building high quality software FAST"

Well I don't understand why people confuse the term "Agile" with speed. Agile development is not about speed but about change (look in any dictonary). Agile development was a kind of revolt against the heavier methodologies since they were too picky and wouldn't let you change down the road, as easily as some of the Agile methods like XP.

Now the practices proposed in Agile methods like XP might lead to a faster development but will never ever guarantee on time developement and never says snything about speed. It is all about adapting to change in requirements, situation etc.

Re:Misconception

[byrd]

Agile development is not about speed but about change

That's true. But being agile means that sometimes, you can dodge the speed-bumps.

the practices proposed in [...] XP might lead to a faster development but will never ever guarantee on time developement

It depends what you mean by "on-time". XP can certainly guarantee that something will be delivered on the appointed release-date, and that it will contain the most important functionality. You relax the scope in order to hit the target. In some non-XP projects I've been involved with, we've been unable to alter scope, and therefore had to relax quality to hit the target. And that's never a good feeling.

Not so good ideas...

[Anonymous Brave Guy]

you've got some good ideas, but let me point out that refactoring time is often lost to time pressure. [...] Of course, in the end, it bites you on the ass and then you have to do more painful refactoring.... but if you did it up front, you might not get to the later as your company runs out of VC....

Sorry, gotta disagree with that. In my experience, maintaining a good design always pays for itself and more, whenever you do it. I've spent months refactoring/rewriting a whole spaghetti design to clear it up. I've also walked in to help a junior colleague who'd spent a week having trouble working with someone else's serial comms code and getting nowhere tweaking it. The first thing I did was spend a couple of hours completely refactoring it into sensible layers. In the process we fixed a couple of serious bugs, and the whole development was complete two hours after that. Are you really telling me it would have paid off to leave him tweaking for another week instead, if you had limited VC funding? :-/

Re:Not so good ideas...

[kaladorn]

No. But a lot of times refactoring is slightly more complex than something that can be done in a couple of hours. Especially if you enjoy the "joy" of having inherited part of a large multi-platform project with multiple applications that have to interop. Assuming the whole thing has been assembled, many times perhaps to satisfy requirements for rapid demonstrations, etc. in order to acquire sales leads, etc, then refactoring becomes a large task in and of itself.

Of course, in a perfect world, this would never happen. If you happen to live in one, let me know where and I'll emmigrate.

The definition of bite you in the ass later is: Costs you more to fix later than it would have to do right in the first place.

This hinges on several factors:
1) That, by the time you later refactor, your own knowledge of the situation/requirements/code/etc hasn't improved drastically
2) or that by the time you refactor, some change hasn't altered your requirements radically thus making your refactor actually a redesign (so if you'd refactored before, perhaps you wasted your time and money)
3) or that a dollar today and a dollar six months down the road are equal - which isn't true in many cases... a dollar now may be something scarce and so refactoring time is VERY expensive, and later that same dollar (or even two given it will be harder to refactor) may be less problematic and more affordable

I distinctly recall drawing the distinction that it depends on situation. In some cases, it makes sense to refactor always. In some cases (especially where you inherit a large, convoluted code base but have to start working on features without uptake time), refactoring immediately is a dumb idea. In an emerging market, refactoring immediately may well be wasting your time as that entire feature set or product direction may be entirely abandoned.

So, although I support refactoring, I think the real world shows us places where it takes on a semblance of creeping elegance. I myself do it fairly regularly (mostly to make things easier for me and those following to understand), but I've seen the time hit this can incur trying to unravel a messy class heirarchy and I've seen the severing of whole feature sets as marketing/sales scramble for market position. That's why the real world isn't like the inside of any textbook.

Re:My Outlook on Modeling

[alienmole]

Yeah, but expressing deep inheritance hierarchies with wood and paper gets a bit tricky, and objects with large relational cardinalities require extreme care to hook up - doesn't really qualify as "agile"!

Emailing these models can also be a bit of challenge...

But the book is more that that

[SuperKendall]

I'm only halfway through the book, but to me the book is about learning how to recoginize what modeling techniques would be most appropriate to the situation you are in - by evalutating the people and environment around you and doing what works.

Sure most of us have a set of design and modeling techiques we rely on, but this book can help judge which ones really will work with the project you're on. Even in the same company, there can be dramatic difference in what will work best on a project.

Also, I think people tie this book too closely to XP - though it does advocate some XP techniques it does not mandate all XP techniques be used on all projects. I was at a JavaOne talk on Agile Modeling, and I really wish I had read the book before I attended the session as much of the session was wasted on XP questions instead of asking more interesting question at the higher level this book covers.

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

Amen. How many ways can you rehash devel models?

[Ars-Fartsica]

Requirements. Design. Build. Test. Rebuild. ReTest. Deliver. Follow-up.

How many ways can you rephrase it? At least UML provided some sort of vocabulary to the design phase...so the Rational folks can at least say they forwarded the state of the art.

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 !