Hacker News Reader

Comment by mahmud | Hacker News Reader

<rant>

Well written code is approchable without constructs like UML.

ANY code is approachable without constructs like UML. Compare the Addison Wesley "Professional Programming" series (the ones that published APUE, UNP, Pthreads books, etc; the white text with a splash of blue) to the yellow/khaki "Object Series", the ones that published Booch's books and the french dude who was pushing Eiffel, etc.) The difference between the two series of books is essentially UML and "object technology". The first is readable bliss, the later is an abomination cast at us from the bowels of hell.

UML is wankery. It's what liars and crooks push when they lack the sufficient bullshit to make it to high executive positions, and the talent, dedication and honesty necessary to be an engineer. Everytime I met a "software architect" that used that garbage, the person was always nearly clueless and a pain to be with.

</rant>

View on HN

And should we be amazed at your drawing scribbles, boxes, triangles and whatnot? How should I interpret your abstract and masterful artsy drawing?

There's a time and place for UML. Overdoing is wrong, I agree. But that doesn't mean UML is bad. When a project is huge enough, sometime you do need few pictures to help others to understand the big picture. Some people can understand better via visualization.

I'm not sure if others feel this way, but I'd actually rather see someone's free form artsy drawing than a UML picture. I think it's reasonable to expect that a skilled developer should be able to provide an intuitive whiteboard diagram or slide-show graphic. It takes some practice, sure, but I think UML is the wrong solution. UML is constantly misused. Big enterprises love CASE tools like Rational Rose, which push UML way beyond its intended usefulness.

I'd actually rather see someone's free form artsy drawing than a UML picture

I totally agree. The whole idea behind UML is to force diagrams into a set of constraints drawn from a particular model of computing and design (early 90s OO, I suppose) on the assumption that this is the "right" way to imagine software. This excludes the ineffable creativity which drawings are so good for. It's amazing what happens in a good design discussion when people spontaneously pick up a pen at a whiteboard without thinking about it. UML forces people to think about something other than the problem at hand, distorting ideas and breaking flow.

And in the name of what? "We need a standard," they used to say, "so that people know whether they should draw square boxes or round ones, so we can get beyond the notation wars." What tripe.

Quite right. There's nothing wrong with a dash of UML as seasoning or a visual of some actually critical process, but just like you wouldn't want to eat a half pound of oregano on top of your steak, you don't want to produce as much UML as code.

I have included emitted UML (from running code) into my end documentation (from c#/VS world). But for any work I've ever done, there is a unordered heap of back of envelope artifacts that I fear only make sense to me.

It is hard to capture certain details in prose, and a (nearly zero effort) emitted UML diagram can do the trick. Or at least convincingly make it look like you did the trick...

But start from UML? I think I'd rather spend that time polishing my cv.

Reply on news.ycombinator.com