Friday, May 16, 2008

0th reason for UML's demise

Little tutorials discusses why UML has lost. It's a correct, if slighty tedious, overview of why the favourite bullshit "technology" of the 90s failed.

Naturally, it fails to mention the main, zeroth, reason: the sort of people who ever cared about nonsense like UML are also prone to spending countless hours categorizing and discussing the patently obvious.

Sadly, this can be traced as the reason for the apparent popularity of many other "technologies" out there. REST anyone?

4 comments:

Keith C said...

THANK YOU. I am completing the second assignment in two days, for different classes, that requires me to use this "language" (I'm a computer science major, for pete's sake). I am so sick of it that I googled "UML bullshit" and your post came up. You described my feelings perfectly. I feel as though so many of these frameworks are cobbled together by employees simply to justify keeping them on staff.

I also don't appreciate the condescension by those who insist on constantly using UML to demonstrate workflows that you rightly indicated as being "patently obvious". Just because I am a computer scientist doesn't mean I can't understand a simple workflow.

Anonymous said...

I agree - I also found this post by googling 'uml bullshit'. I've been working with a bunch of UML guys since the start of the year, and their zealotry for patently trivial and obvious has driven me batshit insane some days.

Robin Adams said...

A Computer Science professor here, preparing a course on Software Engineering. UML is in the syllabus, and after wading through textbook after textbook, I was thinking "This is bullshit, isn't it? How can it be taught everywhere, and be in so many textbooks, if it's bullshit?"

Thank you for convincing me that I'm not going insane.

Seriously: it's nice to have a standard set of symbols for class diagrams etc., and a tool for drawing them. But there's nothing more to UML than that. There never was.

Joshua said...

I am taking a Modern Software Engineering course, which is fixated on UML. I just wanted to learn a practical and technical skill set that would improve my marketability. I did not realize, and without self-conducting the courses by their syllabi before enrolling could not have known, that I was signing up to study the late 20th century / early 21st century equivalent of hieroglyphs. Stickman walks like an Egyptian, but even in Egypt, they speak an actual human language face to face on an Agile project. UML seems like a, "wink wink nod nod say no more say no more" in the Monty Python sense of it--some bullshit I hope the boss doesn't notice is a massive waste of time. I have to make a list before I can even make the diagram that is meant to precede the list I already had to make. It is required by software engineering rule making bodies for curricula, so that what software programmers do for the first two stages of the SDLC will appear worth developer's paychecks to non-tech managers. It exists for the sake of looking engineered, not actually necessary to properly engineer. The diagrams are just a good way to piss away time. To its credit, stating the obvious is part of the job of systems planning and analysis. However, the idea that one needs to use some wonky visual sign language to do it instead of a seriated list (which naturally mimics functional decomposition) is a sign of a thumb up the ass corporate culture. I don't want to work for or with people who are full of shit.