Iconix Process

A methodology created by DougRosenberg. Some similarities to ExtremeProgramming, in that it's more lightweight than RationalUnifiedProcess...

The IconixOpinionOfExtremeProgramming seems to be better known than the IconixProcess itself.

Let's change that!

It's much, much closer to RationalUnifiedProcess than XP, with the emphasis very much on BigDesignUpFront and coding viewed (reading between the lines) as a job for JustaProgrammer. My experience of ICONIX is that it is basically a trimmed down RUP, the major change being the use of robustness analysis as a bridge between domain model/use cases and the code. Whereas the RUP suggests developing a working architectural prototype in the elaboration phase, ICONIX offers little on architectural issues, instead insisting that design elements should be based absolutely on the use cases. And this can be a real problem...

As the use case mantra demands that use cases detail what the system will do, not how the system will do it, the resulting designs tend to be architecturally weak. Perhaps the architecture will emerge?! Have you ever tried emerging an architecture with no automated tests? Just about every new piece of functionality broke existing code.

ICONIX also says little about testing, other than to base tests strictly on the use cases. Admittedly this is a problem with use-case driven design in general, but at least the RUP places some importance on architecture.

I really don't want to detail the true horror of implementing a large design done the ICONIX way. Briefly, despite 4 months worth of beautifully designed, perfect use cases, domain models, robustnesses and sequence diagrams, most of this analysis was turned upside down in the first few days of coding. The analysts thought the job had been virtually done, that their 4 months of analysis would take around 6 months to implement. It actually took around 18 months, several rewrites and the architecture is still flaky as hell! No change from your typical BigDesignUpFront project there, then. It is important to remember that after the first iteration, coding does not stop, part of the team updates the documentation, check the questions that were raised during the last iteration with the customer, etc, and a part of the team continues the coding and if they need more information they ask the group in charge of the analysis (and documentation) to make those questions to the customer.

Even though many of the RUP artifacts are eliminated from ICONIX, there's a strong feel of 'development as a document processing activity' about it. In case you haven't guessed, my experience with ICONIX has been largely negative. I believe it's strength must be the way it's marketed. Something about it really captures those who don't do much actual coding any more, including those still struggling into the Brave New World of OO!

Of course DougRosenberg could well argue that we didn't do the full ICONIX process or something. Partly true as to actually get the project on track, we've since brought architectural design back in, implemented automated test suites and dumped robustness analysis. -- BrianCooke

I think the trick is to do Iconix iteratively, instead of doing it in a BigDesignUpFront way, in my experience after you explain a team the Iconix process the typical tendency is to waste 1 month in Requirements review, 1 month in Preliminary Design Review, 1 month in Detailed Design Review and 1month in Deployment (and another 4 months trying to update documentation as you code). I think that is wrong approach I remember reading somewhere (if I find the link I'll add it here) that the purpose of the Iconix milestones where not to be executed as few times as possible and with as much depth as possible, but the other way around, try to cover as many use cases as possible, and do each of the 4 steps on them in the most superficial way, and do a little code (at most in 1 or 2 weeks), and then repeat again, until you finish the system.

It is important to remember that after the first iteration, coding does not stop, the team is split in a "coding" team and and "analysis and customer interviewing team", those int the coding team continue to code, and those in the interview the team interview the customer with questions raised from the las analysis and update the documentation (they also gather questions from the coding team to resolve them with the customer). As development continues and if requirements stabilizes the coding team grows and the analysis team shrinks until the project finishes.

The thing I like the most about IconixProcess is precisely RobustnessAnalysis?, because I feel that those diagrams can map really well to the ModelViewController pattern