"Their stated goal was to no longer have to write any code in house, but rather nothing but UML"

This goal was promoted heavily in the late '90s and early '00s. Some tools could supposedly "round-trip" between UML and code, but I never saw that actually work. As originally conceived, UML was supposed to foster communication and there are times when a UML diagram is the perfect means to communicate the intent. I tend to use sequence diagrams and ER diagrams the most (yes - I know ER diagrams aren't UML but they're roughly analogous to class diagrams and what we're usually trying to flesh out is the relationship between models).

As an aside, there were/are graphical programming languages. I wrote a couple of Windows and Mac utilities in ProGraph [1] during the '90s. The ProGraph environment lives on as Marten [2] which I recently played with on Linux. It's not nearly as clean as I remember it being.

[1] https://en.wikipedia.org/wiki/Prograph

[2] http://www.andescotia.com/products/marten/

Sequence diagrams are quite useful, static diagrams, not so much. I only find myself drawing them if I'm trying to do a necropsy to figure out hosed up object relationships.

The other useful diagram tfa doesn't cover is the finite state machine diagram. Handy, plus, they look cool.

As an aside, I find it's much, much easier to do with pen & paper than in any tool i've ever used (looking at you omnigraffle & visio!)

  > UML was supposed to foster communication

  > could supposedly "round-trip" between UML and code, but I never saw that actually work

This is the root of the problem with UML-as-spec: it's used as a tool for one-way communication, for open-loop management that doesn't want to have feedback or dialogue stages in development.

I think this is the real problem with UML. It first kinda seems to work when project is managed with waterfall-style, but when actual development is done iteratively (when is it not?) it just adds confusion or work either by providing out-of-date spec or introducing more stuff to keep in sync.

UML is a way to talk about things. Just having a standard-ish way to draw on whiteboards is pretty helpful, even if the diagrams are super temporary.

In practice in most industries, most folks can probably get away with just knowing the ISA/HASA type stuff and 1..N, * arrity, etc. Swimlanes are also somewhat useful as a concept (but so are regular flowcharts).

There's a whole other ton of UML (see 5/7th of Rational Rose around the early 2000s, which is probably gone all deep and crazy now, etc) that is, IMHO, pretty skippable.

I've not even seen some of the "stuff you have to know" (ball and socket, etc) used.

I do think that designs get better when you can draw them, as when they get hard to draw, it becomes conceptually obvious there may be problems.

UML generation code tools running against 1300+ Java classes and making some huge diagram covered up in arrows definitely doesn't work too well though :)

If you have a problem with out of date documentation, I think you might have a problem with the development team rather than the documentation.

If you don't think the documentation is useful, please get rid of it. But blaming UML for your documentation problems is like blaming English for forcing you to rewrite comments that no longer make sense.

My sense is that people associate bad processes and bad teams with the tools that they were using. Crappy tools exist, and people have had some pretty dumb ideas about how to use UML, but is useful as a way to express aspects of your design that may lend themselves to a more object-oriented approach. This is something for which no other widespread diagramming language exists.

Whether you're using an iterative or waterfall approach, at some point it is necessary to provide some context for your software units, like explaining how they are associated or what their areas of responsibility are. That's all the documentation does.

There are two types if UML diagrams I willingly used: sequence diagrams and deployment diagrams.

ER diagrams are super useful, too.

Do you have link to an example of a "realistic"/real-world deployment diagrams? In my courses they always looked quite silly and useless, but I wouldn't be surprised if that's due to bad examples...

It can be hard to convey the proper use of a technology/framework in academia when there is not a lot of background to work with. I felt the same about unit testing (shouldn't you know how your code works?) and UML diagrams (shouldn't you know the class/object relationships?) as well. They're all bigger picture than that.

The point at which I started to realize the usefulness of diagrams was when I started working on projects that were more than a few hours worth of coding (my first internship). UML provides a way to visually represent how your code will both relate to itself (classes, interfaces, objects) and the overall project to both the developer AND the business analysts who have no idea what inheritance or polymorphism mean. I've included an early draft of a piece of a rather large data model. It won't mean anything to you without the overall diagram, but you see some relationships between the customer's account, application and product: http://s18.postimg.org/gxfkjytft/diag.png

You probably had an example like grocery store checkout software, hotel booking software, or library cataloging software. A UML diagram can show to everyone all the possible routes a customer can take such at starting points, ending points, resume milestones, activities that are and are not allowed, transient and permanent data and everything in between. This all applies to the academic scenarios listed above, but it's more in depth (likely) than an assignment that you'll have when learning about UML.

Just keep in mind that large project will have multiple developers of varying expertise with business people who likely cannot write "Hello World!" in any language. UML attempts to bridge the gap between you, your superiors, your subordinates, and the non-tech side of the project.

Together J had always in sync Code and UML. It was a really neat IDE.

I was involved with one of those UML -> Code systems back in the early 2000's. It was company called Nuevis. I had proposed a simple CMS to be written in ASP (or maybe Cold Fusion). We had a project plan, requirements and design documents and developers ready to start. Some architect said we would be the perfect use case to test this new technology.

We met with them, licensed their system and began to make UML. After several weeks we started to generate code, but it wouldn't run. Several more weeks and we had running code, but were missing key functional requirements. We pulled the plug after 6 months. It turns out that UML class and state diagrams are just not robust enough to explain specific functional details. The system generated thousands of lines of code to do simple things.

We ended up writing it ourselves in ASP, it took us about 3 weeks to code everything.

Nuevis went out of business in the original dot-com bust.

I had a similar experience about 12 years ago - turned out the company in question simply used their UML based methodology as a sales tool. Projects never actually worked that way in reality - what they said they did and what they actually did were completely different. Once I realised that the development process was actually perfectly OK and nobody actually looked at the UML I was fine.... ;-)

I was developing SW in the 1990s (before XP, then Agile, become popular), and we were supposed to use UML, Rational Rose etc. However, that was how it was supposed to work, not how it actually worked.

The biggest relief in starting to use XP was that the methodology described how we actually worked, not how we were supposed to work.

I was on a big project in the early aughts (pure XP, pairing, tickets, stories, tests (40,000 of them at the end) etc), on which, we were contractually obliged to A. hire on at least 4 accenture consultants, and B. purchase 4 rational rose seats.

We simply stuck the accenture clowns alone in a room with rational rose, and we never heard from them again (nor did we ever see any uml). Best case scenario.

I always thought the quality of rational rose itself was the best argument against UML.

After all, that's probably what it was designed with.

Oh my, I can so identify with this.

I used to do product reviews for a magazine, and Rose was the only review software I decided not to keep. And I'd have felt bad giving it to anyone else.

From that time on, any mention of Rose in a job description automatically disqualified it.

I hope UML as blueprint (or even, shudder, UML as a programming language) now mostly lives on in the memory of those who suffered under it.

Unfortunately, I am having two mandatory courses that focus on it (it's a BSc CS programme).

Wow, I remember studying UML in BSc CS nearly 10 years ago. I'd imagine it's much less relevant now than it was even then.

Two courses that focus on it? What school is this?

Carleton University? Christine?

could be anywhere, mine also has a mandatory course on it, including a lecturer that believes in the magic of auto-generated code from the UML tools.

I worked on at least one project that used ObjecTime, a predecessor to UML. You were coding in it, in a very ship-in-a-bottle way. The article completely ignores how state machine patterns are done in UML, which ( IMO ) is where you start to see some gain. This being said, just doing state machines in a non-OO way isn't exactly rocket surgery.

It was tolerable. But changes were a bit expensive, and we kept a reference machine for builds, which was not very nice. The environment was hard to replicate - behind the scenes was a sandbox of Smalltalk and that was sort of ugly.

We did a port to Rose, but Rose was not, frankly, as capable.

What's funny-peculiar is - as described in your experience - the whole idea of "architects that can't code." At the very least there's apparently no market for tools to enable that.

yes this. When I read the title and clicked the link, I thought, shouldn't this page just be blank?

In 2013 I encountered a major IC design company that still works in this way: spec -> complete English+diagrams description of all system components -> Verilog -> production.

I left hardware engineering less than a year into my first job more than ten years ago. I'm curious, how is it supposed to work?

Agile hardware sounds dauntingly expensive!

Part of your story reminds me of the customer of the computer company I worked for that would, every week, print out sales and financial reports that ran for hundreds of pages and about as thick as you mention. The girl who ran the reports told me that the only people who ever looked at the reports were the sales guys who would flip to page 20 and look at the bottom line sales number. It was then filed away in the warehouse, never to be seen again.

Back then, I found it strange that people would cheerfully exchange stories such as yours, stick Dilbert strips all over their offices, swap dailywtf links, and just carry on. I was never able to compartmentalize enough to be happy while also admitting that I live in some Kafkaesque version of Office Space. I remember being told by my seniors that I'll grow up and grow a thicker skin, and that I will accept that this is just how things work.

Now, I'm happy to find out that that is not indeed how things HAVE to work, and I'm a lot happier and less conflicted. And now that we have many prominent examples of more functional and humane corporate and engineering cultures, I'm sad for all those people still toiling away in dilbert-land.

What are your best examples on non-Dilbert-land cultures? I want to go to there.

Startups aren't Dilbert land. They literally can't afford it. They have their own pathologies, of course, but they aren't Dilbert pathologies. (And due to scale, if you are motivated, they are often, but not always, more amenable to fixing.)

You can also look around for medium-sized places where software is the primary product; they can typically afford some Dilbertiness, but not too much, or they get eaten by somebody else. Depends on your tolerance, and on your ability to carve your own defensible niche out.

But either way, the key is certainly to start looking. No, working in Dilbert is not inevitable, but you'll have to take positive action if you are stuck there now.

Absolutely. In addition to startups, I've worked with quite a few small-to-medium sized agencies, and as you say, they tend to have a small but manageable amount of Dilbertiness.

As I see it, the crucial difference between Dilbert and non-Dilbert is responsiveness to unhappiness and the ability to learn from failure.

In Dilbert-land, an entire engineering department can grow to be silently miserable. Outside of Dilbert-land, many people would raise their voices and with enough protest, major change would happen. That's because management knows that bad morale is deadly, and can't afford to restaff after mass departures. And outside Dilbert-land, people tend to not see themselves as trapped, and really will, indeed, quit.

Also, medium-sized agencies simply cannot afford to have more than 10% of their projects utterly fail - their cash-flow is too limited, and they live on their reputation and good relationships with clients. Unlike the Dilberts, they simply can't walk straight into failure over and over.

What is the best way to overcome the conscious or unconscious bias against long-term inmates of Dilbert land?

As someone in the orbit of Berlin startup culture, I'd say the answer is simple - you have to overcome arrogance and ageism.

Let's be honest, those of us who have built careers on the "modern-web-stack running in AWS" tend to tilt in the bearded-hipster direction. I've interviewed people coming out of corporate behemoths, and they're typically older, have families, have a more conservative demeanor, and are a few years behind the HN curve, tech-wise. It takes some effort to cross that cultural gap and recognize the decades of engineering and inter-personal experience that some of these people have.

One thing that helped me was to move. That's obviously a big step. I was unmarried at the time, no kids, and knew I wanted something different, so I found a job in a new city and just packed up and moved.

If that's not in the cards, maybe you could look slightly farther afield in your geographical area than you would normally, or look farther afield in your technical area than you normally would.

It might also help to work on some either open source or other public-facing projects (assuming you can and they don't conflict with your current employment, etc.). Then you show that you have experience other than just what you might have from your day job.

I'm not sure what you're getting at. If you're implying that I casually leaped to the conclusion that it's a bad thing, I didn't; I was giving guidelines to someone who seemed to be implying (s)he wanted out. If you don't want out, more power to you; I'm not really a big "you have to be passionate about your job" sort myself. (It's nice, but it's a bonus in most cases rather than a necessity.)

I think I miscommunicated my point. I was speaking of bias against people who have been stuck in Dilbert Land for long periods of time and are trying to get out, but being ignored by companies outside Dilbert Land because they are inside it.

Ah, I see. My apologies for misreading. But, alas, I have no magic answers. Except for the fact, I suppose, that there are no magic answer in general, and you may have to do something a bit spectacular if you want out, to prove to those outside that you can function outside. This is where programmers have it easy; it's really easy to get involved in an open source community or something, compared to a lot of the other people who can get stuck in Dilbert-land.

The mid/late 90s were this weird time when people were printing things out like crazy. It was after the first cheap inkjet and laser printers came out. I must have printed out hundreds of Yahoo maps directions and other things at the time. I remember possessing lots of big three-ring binders filled with various manuals for programming libraries. At the time, printing was almost free, and email and web were still somewhat lacking in user friendliness for reading docs in the modem and pre-PDF ubiquity days. These two factors lead to this brief printing things out trend.

The printing thing stopped when online help got better and more ubiquitous. Now, I usually read docs on the web and only buy a book when I want to majorly invest in learning a new technology.

I remember in the late 90's I'd download the full set of javadocs to have them locally on my computer so I didn't have to wait to browse them over the network.

In fact I had burned them to a cd-rom so I could pass them out easily to co-workers...

Better than printing them out, but still unthinkable now.

My story was for a dot-matrix printer. Took hours to print.