Comments on: We Don’t Use UML in XP

By: James Carr

James Carr — Sat, 24 Jun 2006 01:50:01 +0000

Indeed … I think that’s always the biggest issue … to keep from doing too much up front design.

By the way, I noticed you put a url down for your name that has a placeholder page in place … you setting up a blog soon too?

By: Adam England

Adam England — Fri, 23 Jun 2006 05:59:55 +0000

Interesting - I’ve worked two jobs post-college, 1 where I was required to produce detailed UML before writing code, and one where half of the developers didn’t know UML. At work, I find UML being used frequently, not to PLAN a system, but to DESCRIBE it. I find it dangerous to do a UML until after you have written code, but creating UML as a way to document a system for your customers and teammates can be useful. It’s not embraced by all agile developers, but it should be - A picture (especially on a whiteboard) is worth a thousand words.

By: Cory Foy

Cory Foy — Tue, 13 Jun 2006 03:46:33 +0000

Good post - when I first came on board one of the first things I did was sketch out a sequence diagram of the system we were working on. My pair was confused, because he thought we weren’t supposed to use them.

I told him that the trick is just not to keep it around - and we didn’t.

By: james.r.carr

james.r.carr — Mon, 12 Jun 2006 12:35:24 +0000

For us it happens while practicing constant refactoring during our iterations. For example, a major component of our new system is a business rule processor. When I came on board, there were only a handful of business rules that were in a pacage called, simply, “businessrules”.

Since then, our businessrules package has split up several times as our number of business rules grew and we could identify rules as belonging to a particular family of rules with certain traits. Liewise, new objects arose over time that took responsibility and roles that had naturally been spread out early on, but as those roles became more common required new objects to play those roles.

By: Chris Chedgey

Chris Chedgey — Mon, 12 Jun 2006 09:53:29 +0000

I kind of just invented the term, but I agree that it’s a good one ;-). We’ve been doing this for a couple of years now and I strongly believe that it is important enough to be included as an explicit principle in XP/Agile processes. Out of interest, how do you discover your emergent design at the higher (e.g. package) levels in order to perform the quick reviews?

By: james.r.carr

james.r.carr — Sun, 11 Jun 2006 16:28:45 +0000

Chris,

Well, at work we use XP and a lot does fall on the team and the actions that the team takes when it comes to design. Although design happens during coding (and may keep design limited and focused on the “task at hand”), a lot of times we’ll reach a point where we decide some refactoring needs to be done to clean the design up.

I googled “Review Emergent Package Design” and couldn’t find any results … could you point me to a definition of it somewhere? It sounds rather interesting as my team currently does quick reviews of where our code has evolved to and, with the larger overview of the system dynamics, can choose proper refactorings based on this.

By: Chris Chedgey

Chris Chedgey — Sun, 11 Jun 2006 15:32:16 +0000

James, I also have the impression that XP-ers don’t do UML. But I think it’s worse than just not having diagrams for communication. It is my hunch that most XP-ers do not do design above the class level at all. Bob Martin writing about REP and ADP doesn’t make it happen. I’d like to see the XP practices include Review Emergent Package Design with every iteration with the view to at least removing package cycles.

Please tell me if I’m wrong on this impression!