Fog Creek Software
Discussion Board




Another Sanity Check, please?

So I was having a meeting with someone who is supposed to be helping us implement the Rational Unified Process.  Now I have been using many of the artifacts from this process for years and I consider myself a very good object-oriented designer and programmer.  This person, in context. explained to me that once you have the basic UML diagram, the members and methods "come from" the supplemental specification.  I requested clarification and she said that the supplemental specification contained non-functional requirements such as "the user interface will respond to clicks within 500 ms" or "The application client will run on Windows XP".

Confused I pressed her on how in the hell such a document would yield your members and methods and she finally replied something to the effect of "I am going to say something rude.  I really admire your cohones (pardon spelling`- not sure) arguing this point with me because I have been teaching this process for years to large corporations blah-blah".  I have been practicing holding my tongue and so refrained from asking question like "have you ever written a line of code?".

Am I nuts?  Is this some obvious thing I am missing?

name withheld out of cowardice
Friday, March 26, 2004

My honest answer to this is that every methodology I've come across has, at its kernel, a very small section labelled "do magic here".

RUP is much the same. You draw the user interaction diagrams, you do the flow things, <magic happens here>, you draw class diagrams with methods and stuff and then they get turned into code and the application falls out of the bottom of the process.

Reciprocity talks about something called "complexity smearing". Which is where the class of people referred to as "packers" shuffle things around and write larger and larger documents, with the end result that the complexity is all broken up and spread out and no single page actually contains noticable complexity. It's still there, but it's hidden inside a lot of words.

A lot of reciprocity reads like the writings of raving madmen, but there are bits of it which sound disturbing sensible.

RUP looks scarily like a way of hiding that complexity in lots of pages so it doesn't look worrying to the packers and they think they've "solved" it.

Now, don't get me wrong here, I think it has its uses.

I think having nice standardised diagrams of stuff like that is REALLY useful. One OO architect drops dead and your replacement walks in and can pick up the documents and read them because they already speak that language. That's a great thing. I sort of wish it had been pushed as being that -- a lingua franca for documenting designs.

Instead it's pushed as a way of getting normal people to do something normal people can't do. Normal people can't do OO design properly. I don't mean that derogatively as such. I can't draw still life, I can't run 100m races {Well, these days I  can't walk 100m races, but even as a kid I was crap at the 100m}. People have various different talents. One of those talents is doing OO design and some people just can't do it. No matter how much paperwork you surround it with.

And at the core of RUP is a small area where you have to use OO design talents.... if you don't have them, it's like having a methodology for running the 100m.

"Step 1: write about running really fast. Step 2: Go and draw a plan of the racetrack. Step 3: go and buy really tight lycra shorts. Step 4: run really, really, really fast. Step 5: cross line first"

It's that step 4 that's the tough one. But if you put lots of emphasis on 1,2,3 and 5 it's possible no-one will notice and then you could probably make a lot of money selling the methodology to would be athletes who think there's some "secret" to being a 100m running over and above being born with the ability to run fast.

Unfortunately, the outcome of RUP is that you end up with extremely well documented TERRIBLE designs. Unless you have a good OO designer to start with. In which case they'd have come up with a good design anyway, but on less paper.

As I say -- if you regard it as a standardised writing system that's portable between companies, the whole thing works OK.

I don't know if that answers your question or not.

Katie Lucas
Friday, March 26, 2004

It's with a 'j' not 'h'.

Just in case you wanted to know.

Andres
Friday, March 26, 2004

Your sanity is fine.  No trainer with "N years of experience" who can't answer a question without resorting to ad hominem is worthy of the name.

Regardless of that, it sounds like you have to work with her (my condolences).  I'd suggest that next time you ask her to walk you through an actual example so you can see how the magic happens.  Sometimes, watching it happen crystallizes everything else you've been reading in a way that nothing else has.  This was my experience on reading the following:

http://www.objectmentor.com/resources/articles/xpepisode.htm

Sam Livingston-Gray
Friday, March 26, 2004

It remind me of the underpants gnomes:

Step 1:  Steal underpants.
Step 2:  ...
Step 3:  Make a profit.

(or something like that)

Personally, I'd ask very nicely if she would be so kind as to help someone who clearly doesn't understand the method by walking them step by step through a concrete example, going from design to working code.  Make sure she understands that she has to demonstrate this to a slow learner so she will need to take really small steps and explain each one.  A brief one day or less workshop should do the trick quite nicely, I'd think.  (Please notice, I'm not saying that you are a slow learner - quite the opposite, in fact.  This is just a good way to set someone up to fail when they have no clue what they are doing.)

Then when she can't do it, explain to her that it's ok, you have actual work to do writing actual code.  Wish her a nice day and send her on her way.

On the other hand, she may actually surprise you by pulling usable and useful code out of thin air by a magic process.  If she can do it, by all means learn what she did and make it no longer magic.  If it's repeatable, it's no longer magic, it's science.

Aaron F Stanton
Friday, March 26, 2004

Ask her to show you how it works with something like Notepad or Minesweeper - walk you through the process.

IMHO, there is a near perfect disconnect between UML and Class diagrams. There is no "flow" from one to the other. UML works okay to draw pretty pictures and help you analyze the more complicated user scenarios, but it doesn't help at all in actually creating the magic boxes that will hold code.

UML is a formalized whiteboard.

Philo

Philo
Friday, March 26, 2004

"there is a near perfect disconnect between UML and Class diagrams"?  are you refering to the other diagrams in UML such as Activity and Sequence?  I only ask because UML has its own class diagrams and they are nice.  I use them myself, usually with something like Dia or Visio rather than Rose.  I am suspiscious of automatic code generation.

If this is what you mean, Philo, then I agree.  My way of doing things has always been to have some kind of requirements document (use cases actually are good for some types of projects) then create an object model and a nice UI.  I guess I always figured that given these three artifacts, good developers should be able to start churning out some code.  This idea that we can step through these other artifacts and the code kind of writes itself, is somewhat incredible.

The problem is that the process salesmen claim this is so and that they have run successful projects that prove it.  I am resigned to following the process.  It's a pain in the ass, but my team is committed to it.  I was just wondering about her one assertion.  It doesn't really affect me because I can come up with members and methods the old fashioned way.  I just thought it was a bizarre assertion to make and I wanted some second opinions on that.

Thanks all.

name withheld out of cowardice
Friday, March 26, 2004

Yeah, sorry - I always think of UML as the other fuzzy diagrams excluding class diagrams. :)

Philo

Philo
Friday, March 26, 2004

"UML is a formalized whiteboard."


Philo, I liked that. Do you claim a copyright on it?

Ignore my ignorance
Saturday, March 27, 2004

Hi name withheld out of cowardice,

Can you tell us exactly how this consultant is helping your team implement the RUP?

Are you currently in a classroom setting or are you actually working on a project right now?

One Programmer's Opinion
Saturday, March 27, 2004

To answer the first question in a RUPish way, let say that there are 3 levels to cover (for business apps, something that RUP is tailored for in my view):

1) domain model level
2) analysis model level
3) design model level

1) is about finding out about the concepts the biz manipulates (e.g. Account, Customer, Contract, Sale ...)

Doing that is useful.

How do the fields,operations & relationships get added to the classes ?
Well, by allocating responsibilities.

Do they come from the supplemental spec ? Of course not.
They come because you have to support them somewhere in your processes. Usually to be found in the use cases and so on and not in the supplementary spec, which speaks about other aspects of the software (FURPS+ stuff excluding use cases).

So, find the responsibilities and try to answer those 3 questions then for the classes:

What do I have to know ?
Who do I know ?
What can I do ?

To answer them, functional stuff and domain stuff have to be examined in a loop.

Supplementary requirements are to drive the technical architecture and will have to be supported by the analsys & design discipline while domain is covered in the requirements  discipline.

Anyway, she's wrong.

I do teach RUP at times and also develop software.

RUP and UML are good if they are kept at their place.

UML as a notation to describe systems (solving nothing, for that you have to THINK!, no notation can replace it)

RUP as a framework from where you can pick ideas to tackle the risks your project faces.

From RUP creators themselves, using all of it will result in delivering nothing.

So, once again, you have to THINK! in order to select what is useful.

The goal is not the process, the goal is running software that works.

And IME, no amount of UML tooling, RUP knowledge and paperwork will save the day if nobody is willing to do the hard work of THINKING!

I happen to be selling UML tools (Enterprise Architect), RUP agent (WayPointer from JacZone Ivar Jacobson's own biz), and other process support software but none of them are of any value if they are not there to support your thinking and creativity.

Since someone talked about packers, I consider myself a mapper and maybe UML and RUP should be considered the result of the thinking of some mappers who were able to write down their internal maps !

END OF RANT

Philippe Back
Saturday, March 27, 2004

And people like that consultant you met are just making a bad name out of a set of useful tools. Yes, *tools* ! Not *religions*.

Philippe Back
Saturday, March 27, 2004

We are currently attempting to create software and not in a class.  This RUP person is part of our team.  She, herself, says repeated that one can use as much or as little of the process as helps him do the project and that for some projects she recommends a minimal set of artifacts.  Of course her minimal set of artifacts seems like overkill to me.

My question with respect to producing each artifact is always "does this help someone on the team do his job".  I originally assumed we could get by without sequence diagrams but my architect now says he needs them because it is inobvious which use cases create and destroy which objects and so forth.  Fine by me, we can make sequence diagrams.

As many other posters pointed out, all this is useless if the teammembers don't think.  I am becoming concerned that we are using adherence to process as an excuse to put off work (coding).

name withheld out of cowardice
Saturday, March 27, 2004

Oh geesh.

Obviously, you were smart enough to read between the lines. What she is really saying is "I've become very skilled at manipulating managers with my fancy acronyms and PowerPoint presentations. I'm making a lot of money pretending to be an expert. Don't stand in my way little man or I will squash you like the bug that you are."

Of course, there is a small chance she does know what she is talking about but she just can't communicate it. Any "expert" in RUP who can't explain things clearly to a developer shouldn't be responsible for implementing it, however.

As an aside, this is one of the reasons that I'm not a big fan of heavy process methodologies like RUP. Besides becoming unwieldy in their own right, they tend to spawn a cottage industry of blowhards who only view development through their own narrow perspective.

Mark Hoffman
Saturday, March 27, 2004

Hey!
What is wrong with manipulating managers with PowerPoint presentations?

Oh, unless you mean that's her *only* talent...

Philo

Philo
Saturday, March 27, 2004

Only I am getting weighed down in process because I am expected to produce document for which I do not see the value.  I kept saying that if you could explain to me why we need this artifact or if the architect or developers tell me it will help them, then I will be glad to produce it.  They keep falling back on the idea that they have seen RUP be sucessful in the past.  It is impossible to examine this claim without causing trouble.

I also fear that the team is using the process as an excuse to put off work- "I can't possibly do my work until I have sequence diagrams".  It also seems to be trying to get people further up the chain to specify exactly what people further down the chain should be doing.  If I am expected to produce a diagram that shows exactly what is happenning in a use case as far as object creation/destruction, method calls and returns, frankly I would prefer to write the code myself and skip the extra diagrams.

It seems to me that we are using the process to turn a three person project into a seven person project.  I'm all for full employment but given that they keep telling us we have a budget problem it is a bit frustration.

I am just trying to keep my mouth shut and limit my complaining to this forum.

name withheld out of cowardice
Saturday, March 27, 2004

Since all projects are contextual, some awareness of the context is in order.

RUP bits and pieces to use should address that context.

Defining precisely what "downstream" people have to do is just impossible in a software project.

I like that concept of the "cone of uncertainty" that Steve Mc Connell uses in its "Software Project Survival Guide Book".

And as he says there: "the person who claims to be able to estimate the impact of those myriad of decisions before they are actually made is either a prophet or not well informed about the intrinsic nature of software development".

So, diagrams and all that are tactical tools, not strategic ones.

I agree that having a sequence diagram showing up the standard interactions between RUP-subsystems is good. Showing all the interactions in there is just a waste of time.

BTW, if you are programming in Java and have access to some copy of Together/J, that beast will do the low level diagrams for you (I used IDEAJ, no diagrams, thank you, I'll do the detailed ones on the whiteboard, for subsystems I'll use EA).

Which artifacts are you asked to produce ?

Philippe Back
Sunday, March 28, 2004

*  Recent Topics

*  Fog Creek Home