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

...Modeling has no place in XP

[WetCat]

it should be done in Linux1

Re:...Modeling has no place in XP

[Anonymous Coward]

I am sad because I am stuck

posting on a Dreamcast

in my shitty hotel room

i can't even login

But happy troll tuesday anyway

I know it's a day late!

I AM ATM

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

[Hektor_Troy]

I have the same problem (single developer), but I just switch to skitzo-mode and work with my other personalities.

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

[Richard_Davies]

I agree with almost all of your points here. Especially iterative development: it is simply _impossible_ for the programmer, designer, architect or client to know all of the requirements perfectly in advance for any reasonable size project. Also, some requirements change - it's a fact of life. Instead of getting angry about this, simply accept it and enable a mechanism in you development process to deal with it - that's what iterative development is all about.

Where I disagree somewhat is with "deliver the most value-producing code first". I would prefer to emphasise:

Deliver the highest risk code first.

For example, if there is a new tool, technology, system, or whatever that you haven't used before and is critical for the project, this is probably the highest risk part. If the project, has strict performance requirements, this may be the highest risk part that requires a load testing framework to be established early and used rigorously thoughout the project. While it is nice politically to give users useful code ASAP, this may or may not be a high risk - if it is, of course, do it first. I really believe that having prioritys being "risk-driven" rather than "user-driven" is a more correct approach.

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.

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

[swagr]

Thanks for the link.

slashdot have special interest in good reviews

[Anonymous Coward]

Look at the fucking BN link, including a sourceid.. someone is getting commission.. what is the point in reading a review when the reviewer (or Slashdot) is getting paid for each book that is sold after reading the review? Grrrr.

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

Re:slashdot have special interest in good reviews

[Anonymous Coward]

some could argue that slashdot has the right to get some credit for referring interested readers to the book

Yes, that would be called an "Advertisement". An article where the publication stands to make money for purchases of the product cannot, where ethical journalism is concerned, be called a "Review".

That way slashdot wouldn't face any criticism for getting referral points.

Let's be perfectly clear, each sale in almost all referral ("affiliate") systems result in the referrer getting a %age of that sale. There is only one possible motivation and that is profit, which could amount to several hundred+ $ for all the books reviewed in a month if all are linked in this way.

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?

Re:News for Nerds: An Holistic Approach

[Anonymous Coward]

I work for behavioral health, so "Affective Computing Disorder", "Agile Modeling Abuse", and "Attentive Debugging Dysfunction". Heh.

Re:News for Nerds: An Holistic Approach

[jo42]

"Analytical Sodomy" by Hemos, CmdTaco and JonKuntz.

Zoolander!

[Anonymous Coward]

Well, hey. That's what you get when you rely no mnemonics instead of semantics. but let's go to the agile modeling web site for the definition in 25 words or less. In other words, concise. Nope. Not there. Damn, another modeling career ended tragically early.

My Outlook on Modeling

[Waffle Iron]

I find that plastic models are easier, quicker and look more realistic, but wood and paper models are more satisfying to work on and give you a better sense of accomplishment.

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

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:Many programmers do this anyway.

[greenrom]

UML modeling seems like a good idea, but often I've found that the tools for it are lacking. My experience with Rational Rose has left a lot to be desired. Many of the useful features like code generation aren't nearly as useful when the generated code doesn't work well with your compiler. In addition, the lack of a good way to represent many common data structures like structs and unions often cause developers to insert things in the UML model that don't make much sense just for the sake of generating the code they want. UML has a lot of potential, but in my experience, the tools for it still have a long way to go.

Re:Many programmers do this anyway.

[abigor]

Yeah, I agree. For me, the UML is more an effective way to visualise object relationships and to provide good documentation for future code maintainers. To be honest, I've never used the code generation bit in Rose. The UML diagramming in Dia works just as well for me. I find that UML helps to make complex inheritance hierarchies a lot more elegant, and it becomes a lot easier to see just what object is using what.

That said, I once worked with a total UML/UP freak who produced sequence diagrams for every public method in our whole project. They were really nice, but it took a reeeeallly long time for him to get anything done. So I guess if you have the time, and that's the way your brain works, it's worth it.

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

Wait a Minute. . .

[Anonymous Coward]

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.

Fascinating..

[Dragonshed]

Its very fascinating that this review should come out now. The entire technical competency at my new job has invested alot into Agile as one of many methodologies practiced. Yesterday some of us were having a discussion about usecases, and how they fit into the agile world, both as a consumable from the developer's view of the world, as well as from the view of User Experience and Project Management. In practice here, it seems that usecases are a very large part of the agile management style, in some cases, depending on the completeness, making it all the way to the client as a deliverable.

I shall give this a read to see what insights Scott Ambler provides.

Please Slashdot this site...

[Anonymous Coward]

It's that idiot who set all the mail box bombs...

CLH model

[avandesande]

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

amazon.com? wtf?

[Anonymous Coward]

Everybody knows that the only place to find book prices is bestwebbuys.com.

Compare:

Bookpool $21.50
Vs.
Amazon $24.49

Re:amazon.com? wtf?

[titonutz]

Compare:

Bookpool $21.50
Vs.
Amazon $24.49

Compare again:
Bookpool - wait for it to be restocked
Amazon - "Usually ships within 24 hours" (from site)

*duck*

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.

Modeling Endevors

[NickRob]

My modeling endevor is to be on the cover of vouge. I'll even take my shirt off to do it.

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:Itterative Development/Refactoring

[VRisaMetaphor]

Overkill is fine as long as you do refactor. It's probably better to design too much and prune than to underdesign and bandage. In fact, I would go as far as to say that overkill + refactoring is a very strong programming practice!

Re:Itterative Development/Refactoring

[Richard_Davies]

Maybe test-driven development may help keep you more focused on what you really need to code? If what you're writing doesn't help make your tests work, don't write it.

Re:Itterative Development/Refactoring

[klorentzj]

what the hell are you talking about?

Refactoring does not have to do with "pruning" your design (which I'm interpreting as making complicated designs simpler). It's actually the exact opposite -- It has to do with making a simple design more complicated, as needed.

The whole idea is that you start off with simple designs (i.e. underkill) and then rely on refactoring to add in additional features later instead of trying to predict the future and making a too-complicated design at the start.

Re:Itterative Development/Refactoring

[VRisaMetaphor]

Man, I think you need to go back and read the book again.

Refactoring has everything to do with making complicated designs simpler. And it doesn't have anything to do with adding in additional features (or taking them out, for that matter). I think you must be confusing refactoring with something else.

Re:Itterative Development/Refactoring

[kubrick]

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.

Murphy's Law dictates that the project you stop doing this on will be the one that would really have benefitted from it. It ends up becoming superstition, a form of learned behaviour... I think you can tell that I'm afflicted with a similar mania. :/

(However, I've been working under extreme time pressures recently, and for stuff that has to be done quickly rather than well -- this has forced me to loosen up a bit. Good, fast and cheap -- pick any two, and we had to opt for fast and cheap :)

(BTW, I don't work for the organisation advertised in my .sig -- just a disclaimer in case people get the wrong ideas. :)

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)

let me know

[geekoid]

when there an Agile SuperModel book. Perferable with a fold out.

Re:let me know

[sharkey]

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

What is Modeling?

[rufusdufus]

I've visited the links on Agile Modeling, and they use the term "Modeling" over and over and over. But no place do they say what Modelling means.

Re:What is Modeling?

[Anonymous Coward]

See Ambler's "Tools and Evidence" online at http://www.sdmagazine.com/documents/s=7134/sdm0205 i/0205i.htm for a good definition of modeling in the context of software dev.

The CQC-S System

[jamesmartinluther]

Caffeine
Quake
Code
Caffeine
Quake
Code
Slee p

Re:The CQC-S System

[Anonymous Coward]

The CQC-S System
Caffeine
Quake
Code
Caffeine
Quake
Co de
Sleep

Shouldn't that be the CQCCQC-S System? Or the CQC^2-S System?

Re:The CQC-S System

[PD]

He unrolled the loop.

Re:The CQC-S System

[rusty spoon]

A proven technique for making the whole day pass faster whilst still delivering the same quantity of output.

In modern systems Wolfenstein replaces the Quake step but somehow absorbs a lot more of time. Dammit.

Re:bn.com? wtf?

[jmagar.com]

Great, not only is titonutz getting modded up, but he's earning money off his link too...

Buy it from my Account instead!!!

Cheers,
Mike

For the Entertainment of the Educated

[Anonymous Coward]

Patrick Stewert was not a skinhead

That's actually quite a hard one to argue, given any picture or news footage of him. Or will you put a toupe on his head for the funeral?

Henry Clay was not a fascist

There are those who believe all men should be judged equally in the eyes of the law ("justice"). These people wrote the constitution of the French Republic, the USA, etc. Then there are those who believe in removing laws which prohibit discrimination, so not all men are equal in the eyes of the law. This is one of the primary characteristics of a fascist.

You are small and fat, and we will write nothing of your death, your simple existance for which noone bothered to recognize.

The death of myself will never reach the media.

Look! You breath now, and no one cares. What difference, then, comes from your death? Perhaps just another parking space at the local supermarket.

Hm, you sound a lot like a great literary figure, how appropriate that you supported Telly Savalas.

Your post, though a troll, is a joke, as is your life.

My troll was successful. You even admit to being trolled, but you're so full of clever ideas-fuelled inspiration that you just had to reply, didn't you? Hehe.

Long live Samual Jackson, he will be missed.

His booty, like his body, will be bustin', and he will only be missed by everyone such as yourself.

hmm, linus doesn't dig Stallman

[Anonymous Coward]

Elsewhere a different subject came up. While discussing the Linux Kernel FAQ, Richard Gooch (FAQ maintainer) promised to add a link to a Free Software Foundation page describing free software. But Linus said:

Please don't.

I don't want a kernel howto quoting the FSF.

Richard replied, "It already has, for years. Like it or not, certain questions/issues *do* get raised. If the FAQ can capture at least some of these, it saves bandwidth on the list." Someone else speculated that Linus "didn't want to endorse the FSF stance that software must be ethically correct." To which Linus replied, "Right. Besides, as the whole notion of "free software" has very little to do with the kernel, please just link to some open source site. One of the more neutral ones is "http://www.debian.org/social_contract.html", for example."

Meta-Troll

[Anonymous Coward]

HAHAHAHA! You g0t 0wned, trollax0r!

They're coming to get you TROLLS!!!!!!

[Anonymous Coward]

Editors... they`re coming to get you, and then you`ll get your balls to the wall, man!

Re:M..u..s...t..resist...

[Anonymous Coward]

. . .A rich, overtly homosexual skinhead

A homosexual skinhead? Where the fuck are you from, Mars? Next time I meet a roving band of "rich, overtly gay skinheads" (I can't stop laughing) I'll be sure to mention your name.

Re:bn.com? wtf?

[titonutz]

Great, not only is titonutz getting modded up, but he's earning money off his link too...

I'm not earning anything. I just copy-and-pasted a link from my browser to my post--no reference to myself included.

Re:M..u..s...t..resist...

[Anonymous Coward]

YBHT, in a post which virtually admits to being a troll. Congrats!

Re:bn.com? wtf?

[beme]

I figured it was because of amazon's silly one-click patent nonsense. And www.fatbrain.com goes to bn now...

*shrug*

Re:bn.com? wtf?

[khill3210]

Bookpool is even cheaper at $21.50 although the book is currently out of stock.

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.

Let me speak on behalf of everyone

[Anonymous Coward]

Judging by the overwhleming lack of response, no one cares about agile modelling.

Re:In case the review gets slashdotted...

[Anonymous Coward]

Thanks! Here's the rest of your comment:

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.

Words, words, words...

[Anonymous Coward]

Buy them, read them, repeat them (and eat them).

This is just a rehash of the old 'good enough' and 'detailed enough' pseudo-methodologia. Software development will never attain engineering status at this rate. Just another notch in the 'mainstream' setback, a la Rational/UML/RUP.

I just wonder what Ambler means by the term 'modeling'...

If real engineers modeled like this, bridges would collapse on a daily basis, planes would fall from the sky, and the hardware that we use on a daily basis would crash and fail routinely (even if not developed by M$). We probably could not even get our cars started...

Btw, 'methodology' is the study of methods, and not a method. Next time, consult a dictionary!

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:Oh, good!

[Anonymous Coward]

I agree. I've been to an Agile Modeling seminar given by Scott Ambler, and came away with the feeling that he's built a little speaking business for himself by putting a catchy name on stuff most good developers do anyway, and riding on XP's coat tails. Virtually nothing new in AM; In fact, most of the seminar was an intro to UML....

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

Re:Hah!

[cpfeifer]

Alright, alright, I'll say it.

YOUR KUNG FU IS BETTER THAN MINE.

There, I hope you're satisfied.

Excellent advice

[Meowharishi]

I wish I could work with Mr. Phallen! He speaks the gospel truth.

Unfortunately, for myself and others in similar predicaments, I work with managers who could really care less about the Zen of effective programming.

Yes, I work for Corporate America.

Where innovation is another word for "troublemaker".

Where its not the quality of your work that matters but the size of your manager's budget and feifdom.

Where great ideas are met with yawns and patronizing paltry interest.

Where its not the technology that drives the boat, but the political connections and process.

Where you have serious questions whether or not you work for Damien himself.

Etc..

Just what I've been looking for

[cicatrix1]

Good, finally a book that will cover how to make the transition from the runway, to the porn industry. Or did I miss something?

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!

Re:bn.com? wtf?

[Anonymous Coward]

If we're going down that path, Bookpool has it for 21.50.

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

Re:Hear, hear

[Anonymous Coward]

try the fireman method of codeing

'OH MY GOD ITS BROKEN WE MUST FIX IT NOW' But that has already been fixed and is going into the next version. 'BUT IT MUST BE FIXED RIGHT NOW' ok ok ill take the time to move the code backwards. Good thing it hasn't been tested yet because the customer sure is going to get to try it!

Do I have some code to introduce your boss to. 'who the hell made this function 10000 lines long?' 'oh he doesnt work here anymore' OH goody I cant even ask the bonehead what the hell it is supposed to do. Too bad its one of the most critical pieces of code in the system and no one around here knows how it works.

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:Not so good ideas...

[len_harms]

Most people forget that a schedule can be changed. It is not carved in stone. The end date may be carved in stone. But what the project does... You also need to know when to chuck things overboard to get things done. It may be cool to have the splash screen popup. But do you HAVE to have one? Could you use that 3-4 days somewhere else? These sort of things should be hashed and rehashed all the way through ANY project. Refactoring can be a tool to _HELP_ you get things done on time. But sometimes we get rather miopic on what we are doing.

Also when you are redesigning/rewriting/refactoring something how can you not at least LOOK at what the other person did? That will take some time. Just to say OH I know what it should do may not be true. Maybe they ran into some problems you didnt even THINK of and they alread solved them? Also more than likely other parts of the system are dependent on the behavior of that 'broken' piece of code. How do you take that into acount? These are the sorts of things you do when you are redesigning things.

But you have it right about knowing WHEN to refactor. Just because someone does not work with you anymore. Is almost always the wrong reason. Sometimes if it works dont touch it is a good thing. You can work on OTHER things that will help you. Other times it finaly just comes down to 'NO ONE' knows how that damn thing works and we need someone here that knows it 'IN and OUT'. More than likely if no one else can even figure out what it does, and how it does it. It probably is a good candidate for getting refactored. But more than likely in order to tear something like that appart correctly you will have to understand the old code.

You just need to know when to pick your battles.

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

"Everyone knows"

[jlusk4]

...Amazon is evil. (Except maybe you.)

Eh, what of it?

[Perianwyr Stormcrow]

They did bring it to your attention, after all. That's generally the role of sales, and in this case, an affiliate payment is certainly fair enough.

Not like it costs you any more, anyway.

Re:Eh, what of it?

[Anonymous Coward]

Not like it costs you any more, anyway.

Of course it does. If the affiliate payment didn't go to Slashdot, it would go to the site, and they wouldn't have to bump up the price of the books to make up for their affiliate system.

The more immediate cost is the one of a biased review causing lots of people to buy a book that isn't as good as claimed.

Re:Eh, what of it?

[SEGV]

Except that the reviewer (the person writing the review) doesn't get that payment. Reviews are voluntary. Write one yourself.

Yo dudes, how can you 'errantly believe'??

[Anonymous Coward]

errant Pronunciation Key (rnt)
adj.

1.Roving, especially in search of adventure: knights errant.
2.Straying from the proper course or standards: errant youngsters.
3.
a.Wandering outside the established limits: errant lambs.
b.Aimless or irregular in motion: an errant afternoon breeze.

Perhaps you meant 'erroneously'?

erroneous Pronunciation Key (-rn-s)
adj.

Containing or derived from error; mistaken: erroneous conclusions.

I'm always amazed that computer geeks who can memorize tons of protocols and languages that basically do the same thing, can't tell two words that mean different things apart...

Re:M..u..s...t..resist...

[Anonymous Coward]

Where the fuck are you from, Mars?

He was wealthy, he was gay, he was bald as an infant's ass, and he didn't like immigrants. How was he not a "rich, overtly gay skinhead"? Incidentally, the fact that such a character could be a serious politician proves how much more interesting politics can be when it isn't completely 0wned by corporations.

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.

Agile Model? I Know of One:

[dupper]

Here's an agile model.

Moderators, I realize your brain says "-1 Troll", but the rapid movement of your collective right hands suggests a "+5 Informative", perhaps. ;)

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 !