Hacker News new | comments | ask | show | jobs | submit login

I love UML. UML is overused. More people need to know UML. The less UML you do, the better.

I believe all of these statements to be true.

I had a contract many years ago with a large insurer. Their development process basically consisted of drawing really complex UML diagrams, then hitting the Big Red Button and having the modeling tool generate 40,000 lines of framework code. The chief architect explained to me that really the only work required was just a tiny bit of business logic in the appropriate places.

Fortunately I was not part of the main dev team, which for some strange reason (at least in the lead architect's mind) had the damnedest time with this system. My job was to create an internal permissions system. Given app X, user Y, and action Z, was the action allowed or not.

I looked at the problem for a while, and no matter how I thought about it, to me I had three lookup tables and one method. Boom, I'm done.

The lead architect wanted me to still draw a diagram with one class, push the button, and get the 40,000 lines of code. For some reason, this did not appeal to me.

Took me about 3 weeks to convince him that really 20 lines or so of code was all we needed. I still had to draw the diagram, though.

That's the horror story -- one among dozens I have. But on the flip side, I've been with teams that interviewed the customer while sketching out a domain model. Since we all understood UML, a quick and lightweight sketch using the appropriate notation got agreement on a ton of detail just taking 30 minutes or so. That would have been very difficult using a conversation or word processor. Sketching without some common lightweight understanding could have led to rookie errors.

There is nothing in this world better for getting quick technical agreement on complex problems than group sketching using lightweight UML. The trick is sticking to the absolute minimum.




I tend to agree. I studied UML and earn certs. At the time, I really liked it and I had fun drawing diagrams for both new and existing projects. Now, I only use it for sketching and I think the vocabulary is the key: it is more important for you and your team to know the important terms than the nuances of the actual spec. For example, the transitions on activity diagrams have sophisticated semantics for describing events, functions, etc. that may be more cumbersome to document and explain than, for example, a label just saying "convert to binary".

In my career, I have only seen a few things that caused religious fervor on any significant scale: XML and UML. But I would like to know if the level of specification around these languages is the off-putting aspect or if it is something else. Did mathematicians of the Newton-Leibiz time exchange letters denouncing proofs or trolling with irreducible polynomials?


I agree. Ten to fifteen years ago I saw stream of UML horror stories. The tools were expensive, complex, and you never needed or wanted 90% of what they could do. But PM's loved to show a stack of paperwork to the client.

Now something like Lucidchart is a great way to knock out some swim lanes or ER diagrams without the nonsense of automatically generated code. You can use the diagrams to get your team and the client on the same page without UML becoming a religion.


One of the most productive comments on this thread. Thanks. ;-)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: