I use Visio to model out the main classes and methods when doing a design. Once they make sense I'm more or less done with UML. Part of the benefit of using UML is it gets things clear in your own head before you write any code. I don't see any benefit at all in exhaustively modelling everything since the chances are it will not match reality.

Modelling after the fact seems like a pointless waste of time unless the environment contains tools to do it. There might be benefit in copying models generated from the source out of Eclipse / Websphere for documentation purposes.

And in my own opinion I'd run a mile from anything made by Rational. I've never use a tool of theirs yet which has justified the expense, complexity or bugs that come with their tools.

Isn't this really obvious? It's not about UML, or agile, or even about software development. All this article says is that when you have tried, and failed, to do something, you are in a mess. Attempts to retrieve the situation are likely to be doomed from the outset, unless the project is restarted properly - with a fresh budget, deadline, and plan. And probably a fresh team too.

Not only do I agree that drawing exhaustive diagrams of an existing poor design is not useful, I would add that too much detail at any stage reduces the value of a diagram. I recently posted 3 rules for effective UML at http://outofthetriangle.wordpress.com/2007/10/06/effective-uml/ and one of them is “Keep it simple”.

Having said that, a diagram that gives a simplified view of an existing system and highlights specific design flaws can be a good starting point for a re-design in some circumstances (even if only as part of a business justification for a total re-design!).

... and if you drive on the right side of the road you will have less accidents!

Really, why do academics come along and write a paper on something that is obvious, scope it to some particularly issue and then call it a new revelation.

This is a symptom of a bigger malaise.

I've just been talking to a friend about the problems in ICT. Ten years hence, clever agents interviewed you in a pub and kept a whitelist. It was essentially an IQ test, and a check to see you don't smell, and aren't a bigot.

They then felt able to put you forward for a whole load of jobs, even ones you'd never done before, because they knew how clever you were.

In recent years, the recruitment in IT has become mechanised, so non IT literate people can do it. This is to the detriment of ICT as a whole, but good for the economy, as it gives money to people who can't do the job, as a side effect of the job. Government's love redistribution of wealth.

An extremely intelligent manager needs an extremely intelligent member of staff, to solve a problem, so asks the most ICT illiterate members of his company, HR, to pass a request to IT semi-literate modern agents, who then keyword search Cvs for the buzzwords in the tiny CV summary that isn't too long for agents to read.

The result is the ICT manager only gets to see some random group of people non ICT literate people think are useful.

He doesn't get the person who is going to solve his problem, he gets the guy with the most references to UML. This is undoubtedly some guy who has done nothing else. Some of the most unproductive, and in the case of UML, overpaid, people I know are single technology specialists.

This almost causes cvs to become a work of fiction.

My best guess is

HR - IQ max 110,

Agents - 1% @ 140 IQ, 99% @ 100 IQ.

Testers - 120 IQ.

Average developers 130 IQ.

Designers 140 IQ.

The two people who do all the work - 150 IQ.

People who caused the problem, ie those who got their MCDBA/MCSE/UML qualification at their Nth attempt, IQ 90.

It's just a disaster waiting to happen.

Anyone who has ever heard the phrase "Could you make your cv a bit shorter, it's not me that doesn't understand, it's HR you see." or "I'm just looking though your cv, so how many years of JAVA/C#/SQL/Oracle... do you have?" (or the most concise indicator that you should hang up the phone, if you hear the word "done" instead if "did", or the word "yourself" instead of "you" - "Does this sound like it interests yourself?") has seen the rot setting in.

I'm with Tom on this one. Why does the example suggest a project in trouble would suddenly start modelling? I've seen a lot of strange things but not modelling at the end. And if it did happen it would clearly be mental.

What does tend to happen is that the 'management' fail (or refuse) to see the gap between reality and the plan until the cracks are so big their bonuses fall down them. I was on a project once where we relocated the entire team to the customer site for final 'testing' (aka finish the development that had been in progress for the previous two years). Only after another year, with all of us on ridiculous expenses, did the customer twig that we were very far from delivering indeed.

Still.. I'm in managment now so I don't have to think about reality. Just plans.

The only constant is change. The only lesson learnt from history is nothing is learnt from history. The only lesson learnt from failed IT projects is ......what? The only constant is change?

Was that project in Sweden?

I've been brought into two different projects where they basically summarized it saying, "So this 'six week' project's now a real mess, and at week twenty, they're way over time and budget. We want you to go in there and model what they have so that you can point out to them what their problem is." I agree, it makes no sense. I'm just saying, it's happened to me, and on two of the three disaster projects I've been brought in to fix.

In both instances, I figured out basically what was wrong within about 2 seconds of starting to look at their code. When the first 80x24 screen full of code is

- full of code - almost no unnecessary white space.

- less than 10 virtual lines long (i.e. average line length greater than 140 characters)

- written in three different languages

- more like line noise than any non-sed program has any right to be

*and*

- full enough of semantic ambiguities such that you can, within that first two second glance, spot at least two places where the way the language parser will read some code is probably different from how the programmer expected - and possibly even variable depending on which version of the language parser is used

you know you're dealing with a fairly special project. Modeling won't help. Additional fun can be had if one of the languages is perl, with half a dozen or more command-line switches being used, none of which were -w or -T.

Unit tests, as a general rule, will help. In my case, on one of those projects, we weren't able to get any unit tests to actually pass any of the existing program - that was fine, because management wasn't watching closely enough to ensure that we used any of the existing program, and so "we" (meaning I) had it working in less than three weeks. The original programmer was either clueless enough that he didn't notice that his files, while present in the directory, were not being used, or he was smart enough to not complain, as this would've indicated that I did in three weeks what he couldn't do in twenty.

In the second project, unit tests plus stringent version control enabled the project to go forward. The first step after getting the unit tests was removing all of the testing cruft they'd added in their feeble attempts to get the program working, and the second was to actually format the code - which showed almost half of the problem, as they had indented so inconsistently that they weren't aware of what the nesting level of each portion of code was.

This having been said - as I didn't actually try modeling, I can't really state absolutely that modeling wouldn't have helped. But I can't imagine getting either of those projects finished quicker without removing management obstacles to fixing them.

I also fully admit to having failed in both cases: I was unable to relate to the earlier staff exactly what went wrong. However, in both cases, I believe my reason for failure was a management thing: management had conveyed very clearly that I was to not, under any circumstances, explain to the original teams that they were fscking incompetent morons. Given this dictate, I found it difficult to relate to them that their problem was that they were fscking incompetent morons.

Oh, and one last comment: if anyone ever tells you the best design for something is to have most of the code written in a blend of awk and perl, with a Bourne shell wrapper around them to glue them together, they're wrong. Either write it in perl or in awk. Either language should be sufficient for the job. If the job involves processing multiple files, and you're not sure how to do that in awk, either write it in perl, or write the handling for each file in separate awk scripts, and have a common script invoke them. And having the in-line perl and awk bits of your Bourne shell script making subshell escapes is just right out.

No. Although that would have added an interesting dimension to it. It was in Lincolnshire (the supplier was based in the Thames Valley) and more than that I probably shouldn't say.

Although everything I know about fine wine, fine dining and doing all your laundry on expenses I learned that year, so it wasn't a complete waste.