Why UML won't save your project
Modelling a badly thought-out project just doesn't help...
The project's been wobbling along for 18 months. A bottle of champagne just went to the tester who logged the one millionth bug in TestDirector (and everybody cheered), the lead programmer looks like a raccoon that's discovered a departed junkie's heroin stash buried beneath a tree, half the programmers have quit, and the customer believes everything's fine... Although it does strike him as odd that all he's seen so far are static screenshots and Gantt charts with every single task stuck at "90 per cent". The project's in trouble.
So what does the team do? They've read the IBM/Rational marketing blurb, so they firmly believe that they can "do UML" on their project and that this'll have a miraculous effect on the bug-riddled codebase. It's this vague desire to start doing the right thing in order to save the project that can sink a team even further into the swamp.
When a project is in trouble because of a lack of initial analysis/design thought, the worst thing to do is to stop everything and start modelling the whole sorry mess in a CASE tool. It seems reasonable to want to create a clear picture of where you're at: a level playing field from which to start fixing the design. But muddy water poured into a crystal flute is still muddy water. Now you've got the same dysfunctional mudball in two places - the code and the UML model. Great.
It's also tempting to automatically reverse-engineer the code into class diagrams using a modelling tool. This might have an unseen benefit in that it'll shock whoever sees the resultant diagrams into realising just how bad the problem has gotten, but the diagrams themselves will be as scary as the code they're modelled on, a jumble of criss-crossed lines and teeny-tiny overlapping boxes that could rival anything in the Tate Modern.
I'm a great fan of UML, but like any tool or language it can be misused horribly – and usually is, because people start to use it for the wrong reasons, e.g. to do the thinking for them or make their team cleverer.
The right time for drawing diagrams is near the start of the project (or new feature, or weekly/monthly development sprint) when you do a little collaborative modelling with the whole team involved and figure out how it'll all fit together.
So it's worth emphasising: the solution is not to start modelling the existing illogical codebase in UML. However, do map out your ideal new improved design, unfettered by the constraints and design dead-ends of the current system. But the first thing to do (assuming you can't just scrap it all and start over) is cover the existing code with unit tests so you can begin refactoring your way to the new design.
But even before that, you must know what it is you're actually designing. Start with the basic questions: Who's the project for? What problems is it addressing? If you're feeling especially virtuous today, map out some use cases and try to drive the new design from them. Don't be afraid to come up with something very different from what you currently have.
UML used at the right time and in the right way can work wonders - it'll set the foundations for a successful, well factored project. But, to adapt Frederick Brooks' famous law about the perils of adding resources to a late project, stopping to map out the bad design on a late project will just make the project later.
Matt Stephens co-authored Use Case Driven Object Modeling with UML: Theory and Practice and Agile Development with the ICONIX Process.
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.
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
- 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.
Constant project failure changes nothing
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?