Slashdot Mirror
UML Fever
CowboyRobot writes "Queue has a couple of articles about UML:
Death by UML Fever by Boeing software architect Alex Bell
describes the problems that can result from over-reliance on modeling tools, with lighthearted lessons for the software development process in general and numerous illuminating quotations, such as: "Good judgment comes from experience. Experience comes from bad judgment. - Jim Horning."
Then, one of the developers of UML, Grady Booch of IBM, follows with The Fever is Real, in which he explains the motivations for creating the language, how it's used today, and where he expects it to go soon."
I don't think his point is that projects are too unique to be guided by such rules. He's merely saying that design patterns are often useful, but don't make sacrifices in your own design to adhere to specific pattern rules. It would be foolhardy to think that most problems could be solved by using straight from the text patterns.
Also I think he's driving at another point: you should only model as much as you need to. I think modeling is useful to help everyone understand how the system works but it's not always necessary to model every behavior before you continue with the project.
Pretty widgets? What pretty widgets?
I found a significant design flaw with a pattern that they were using everywhere and raised it as an issue. Turns out they knew about the flaw but didn't want to fix it since they would have to redo all their UML diagrams for the bulk of the project.
Then they had the nerve to ask me to signoff on the design. Further they had the nerve to ask me to use UML on my next project!
UML is really great for communication of designs. But if you invest too much into the UML you end up "coding" the proposed design and it becomes too hard to modify.
Where UML really shines is in HUGE projects, where systems analysts design the system in UML and programmers write the code. Anything else it's a little bit of overkill and a little dangerous.
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization"
The leading building corporation would proclaim that there's nothing wrong with the buildings and a new market of woodpecker traps and anti woodpecker missiles would thrive.
Who uses UML? The designers or the programmers?
I should imagine the designers wouldn't be very good at it, and I should imagine that programmers would have better ways to express themselves.
Actually a good designer probably has some experience coding. As to who uses it? Well ideally the designer or project leader should author it and the programmers should be able to read and understand it, so both parties technically use it.
Pretty widgets? What pretty widgets?
Aye, laddie.
Be thankful of the fact we've (as humans) have been building shelter for 20000+ years.
As software developers, we've been making stuff for a little over 50 years.
We are In the MudHut age of Software Development:
Garrett's Rule #3: "MudHut software" We are continually re-writing software that performs the functionality we require, simply to make the software run on the platform that we rewrote, so that we can make better software.
You see, 20,000 years ago, our clever, but inexperienced ancestors had to make new shelter every few days/months/years/whatever, simply because they made them from mud.
When the next wind, rain or hail came, it outdated their technology, and forced them to upgrade.
took thousands of years to make the difference, an build structures that could stand up to the changing environment.
So, just when it looks like MS will rule the desktop forever, just remember, while some clever frickin' caveman probably added the first straw and dung to his hut, and improved it, it never lasted. Cooler heads prevailed.
Now, for those who didn't catch it: I just compared MS products to shit and straw.
Thanks,
"...In your answer, ignore facts. Just go with what feels true..."
Let's not forget that a pattern is a solution to a problem in a context. If the context does not match your situation, then don't use it - even if the problem is the same and the solution is attractive.
When these overlooked potential pitfalls, start to pust the project dates further and further away, the entire s/w development cycle is compromised and lot of design work is bypassed. Most of the functionality is directly coded from the requirement specs, bypassing all the UML stuff.
And there is the issue of Change management, Over the lifetime of a project , lot of staff changes including developers and designers, and the documentation and UML stuff starts to lag behind the current implementations. There comes a time when the UML diagrams represention is no where near the current functionality of the Code.
Having worked on two very long maintainace projects for very rich clients , I can tell you that initial project delivery is only the tip of the ice burgh. The real deal is maintaining and upgrading the project over a long time, and sadly UML is very inadequate for that.
From a developer's POV , who needs to work on someone else's code ,Nothing and really Nothing is as useful as proper comments in a code.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
The moral: There are no magic bullets.
This analogy is flawed.
Programmers are NOT to programs what builders are to buildings.
Programmers are to programs what ARCHITECTS are to buildings.
Builders are to buildings what COMPILERS AND MAKE UTILITIES are to programs.
Now, I suggest that you make an architect work under the same constraints as a programmer:
1) I cannot tell you were the house will be built, so you cannot estimate heating/cooling, snow loads, etc. Can't it figure it out itself?
2) I cannot tell you that the house won't be moved to a completely different climate once built - can't you make it automatically adjust?
3) I cannot tell you what building materials will be available to build the house with. Can't you make your design work just as well with wood as with adobe?
4) I cannot tell you how many rooms will be needed. Can't the house automatically add rooms as needed?
5) I cannot tell you what services, such as electricity, water, and gas, will be available. Can't you make the house work just as well on wind power as grid power?
6) I can tell you that whatever I told you is subject to change without notice.
7) Oh, by the way, now that the house is almost designed - Add a hanger. No, I will NOT tell you whether the hanger is for a Cessna 182 or a 747 - can't you make the hanger figure that out when I park the plane?
8) Oh, the house cannot cost more than US$10,000.
9) Oh, and the house must be build on a quarter-acre lot.
10) Oh, and the house must be ready to move in tomorrow. Morning. Before I go to work.
11) Oh, and the house must be built by two dain-bramaged monkeys with Nerf Tools.
12) Did I mention being earthquake-proof?
13) Oh, the lot is in a floodplain. Can you make it water-tight? Or float? Or both?
14) Hey, how about a houseboat?
www.eFax.com are spammers
The main people who use UML are Consultant Software Architects, who come into a project. Create a solution, and provide the UML framework, and collect a big fat pay check. They then move on the next project.
Meanwhile, the programmers who are stuck with this static UML framework, while the timeline, user and system requirements are changing, are put in a precarious situation where the design just doesn't work anymore, and often the project crumbles.
Back to the Architects, who claim there design was adequate for the problem, and they don't understand how the project failed. Must be the programmers.