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

I've generally found UML to be a complete waste of time.

I'd rather outline the major components of a system by drawing (on real paper) simple boxes and lines, or write the code that implements the system.

Not sure what code-as-picture achieves - it's generally has worse tooling (less editable, less versionable, etc.) and tends to be used by 'architects' who don't write code, only for that UML to be essentially ignored by the coders on the ground.




As long a the "simple boxes and lines" describe the functionality of your design at the level you wish to communicate, then you're doing good. You can stop reading here.

The problem is that complex systems need complex design. As your design get more sophisticated, you need more sophisticated ways to communicate the design. Concepts like dependency, multiplicity, inheritance, inclusion, asynchronous message, exception, timed event are all things you can represent with boxes and lines, but unless you adorn the diagram with a huge amount of text you're not going to capture the distinctions between those different types of relationship.

It's not unlike any other language: I can use the word thought to describe something in my head that isn't physically manifested, but words like lie, memory, hypothesis, idea, belief, image, nostalgia, forecast, imagination are all used to distinguish between types of thoughts. If I used only simple words like "thought" then I wouldn't be able to express anything more sophisticated while still being concise.

In short, if you want to graphically describe something complex, you can either use a sophisticated visual language to do it concisely and unambiguously, or you can use a simple visual language and write tonnes of documentation to support it, with all the problems of attention, ambiguity, and rot that go along with it.


    The problem is that complex systems need complex design. As your design get more sophisticated, you need more sophisticated ways to communicate the design
I've never found any need for a third, intermediate level of sophistication that sits between code and natural language + informal diagrams.


In programming for science, engineering, finance or cryptography, you may also need the math, but UML does not help there, either.


"The problem is that complex systems need complex design. "

No. Complex systems need more thinking and refactoring until they are less complex.


Really? The device you're reading this on probably contains more complexity than it's possible for one person to understand in a lifetime, and that's one device.

It's incredibly naive (or at best disingenuous) to assume that complex systems can be reduced by thinking and refactoring. Perhaps some can, but when you consider many of the software artefacts we use daily (seeing as that's the context of this subthread), such as operating systems, virtualization platforms, or even good ol' clunky enterprise applications, you can't just wish the complexity away with a bit of hard work.


I don't think anyone is arguing that complex systems don't need some kind of up front high-level design - what we are arguing about is whether UML is an effective format for design artifacts.

I'd be pretty surprised if any of the code that I am using to read this was designed with detailed UML diagrams.


>Really? The device you're reading this on probably contains more complexity than it's possible for one person to understand in a lifetime, and that's one device.

It wouldn't have been possible at all if the pieces that make it up weren't loosely coupled.

>It's incredibly naive (or at best disingenuous) to assume that complex systems can be reduced by thinking and refactoring.

It's naive to assume that you can't. Loose coupling pretty much only comes as a result of extensive refactoring.


...and one of the ways you can communicate such coupling is by diagramming the (complex) system's design.

Google for "linux kernel diagram"[1]. It's quite well designed, displays loose coupling, high cohesion, and all the other things we like about good complex systems. If I want to dig in and start working on a module, I'd still have to understand the relationship between all the bits I work directly with (and probably some that are further away).

Don't confuse loose coupling with low complexity.

https://www.google.com/search?q=linux+kernel+diagram


Exactly - I think the more complex the underlying system the more effort has got to go into finding suitable very high abstractions - you have to step away from the detail and that's something that UML seems to have a really hard time doing.

We already have a perfectly good way of representing the details of a system - it's called source code.


> We already have a perfectly good way of representing the details of a system - it's called source code.

Interestingly enough, that's a bit of a false dichotomy.

Imagine it's your first day on the team, and there's thirty classes (or thirty functions) in this software package, and you want to understand their inheritance/composition, what's a good way to take a step back and just see how they relate to each other? You can browse some interface files or some source files, accumulating a model in your head. But the visual throughput into your brain is just so much better when you can see it in a diagram.

Regardless of whether a human draws the UML representation of the design in advance of the implementation or a machine deduces this from the existing source code, you can still benefit from a class diagram that will cut out the noise of the implementation itself. As long as we're drawing a diagram, why not have a common way to represent the concepts we use in software?


If I wanted to see a class diagram I'd simply use a tool to generate a class diagram from the code - which I'd then know was completely up to date.

Edit: DRY


Nothing about UML specifies its use in relation to when or how you wrote the code. Like I said, it's a false dichotomy to suggest that we can have source code or UML but not both. Yes, UML diagrams or any other design docs rot quickly. But like you said, we can generate diagrams after the fact too (or in lieu of ever writing UML diagrams before coding).

> perfectly good way of representing the details of a system - it's called source code. ...

> simply use a tool to generate a class diagram from the code

Once you resolve to generate that class diagram you have a choice in how to represent it. UML is just one way, proposed as a standard way, to represent that visually.


Except when you are selling a closed source binary which must be specified to the very small details (e.g. accounting systems from an external vendor, sometimes they are not buying the source code - and you don't want to sell it either, since they are going to replace you...).


Your statement is only somewhat correct. What complex systems need isn't a single, complex design document but rather levels of simple, intuitive design. It's like OOP--the basic principle of OOP is that you can manage (but not eliminate!) complexity by sharding it into small-ish objects that only need to know about those whom they interact with. Similarly, in a large system, you'd want a high-level, very abstract design detail, and as you peer in closer to the code, you want increasingly concrete design.

The problem of UML is that it tries to be the language of all these levels of design (and even different stages of design!), to the point that the highest-level design document is trying to be something so completely specified that there's no abstraction.


> I'd rather outline the major components of a system by drawing (on real paper) simple boxes and lines,

One of the most constructive things you can do when designing software as a part of a team is to review these diagrams with the team. Inevitably, if you create boxes and lines, you'll need some sort of legend that identifies the relationships established by the visual style of boxes and lines. UML is intended to be a common legend, like the schematic representation of circuits (resistors, capacitors, diodes, grounds, etc).

> Not sure what code-as-picture achieves - it's generally has worse tooling (less editable, less versionable, etc.) and tends to be used by 'architects' who don't write code, only for that UML to be essentially ignored by the coders on the ground.

An error that happens more often than we'd like to admit is when we totally mis-assess the requirements or omit big portions of an element's design. Sketching a quick diagram that shows "the UserAccount has a user_name, user_id, and a password_hash element" allows the team to sanity check the design approach -- "Oh, but a UserAccount also needs an email_addr element." "Are you kidding? How would we email them, there's no interface for that on this system." It's sad, but sometimes entire (enormous) features like this don't get caught until much later in the design cycle.


Having conversations about what the system being architected/designed/planned is going to do can be very useful.

There are definitely better techniques than waiting until someone quibbles a field in a lines-and-boxes design session to pull that kind of insight out though. Just sitting around and telling stories about what the user will be able to do, and how they will be able to do it can work wonders.


UML is best when used informally. I find that some bits and pieces, like class and sequence diagrams, are useful for sketching ideas and communicating them.

But of course, that is exactly the opposite of what UML set out to achieve: a system so formal and complete that it could be used to generate code automatically.


I totally agree with picking bits and pieces. My favs were the state diagrams. I remember a couple of times when they saved the day. It was a matter of communication with the customers, a way to show them that their initial description was light years from a real specification and make them commit with the agreed diagram.

Believe it or not, the customers understood it perfectly, after some minutes drawing and deleting lines. There was never a single complaint about that module and only minor bugs, not affecting to the functionality.

I hated use cases diagrams, only useful for CYA purposes. The classes diagrams that I've seen in the wild were E/R models translated to UML, but they were the most part of documentation for some projects, so it was better than nothing.

The traceability systems from requirements to complete UML diagrams to code were a bunch of good intentions that fortunately never materialized.


Things like that existed. But the world yawned.


UML cannot be appreciated out of its context, both socially and technologically. It was created out of big projects at a time where big things were the norm, and then became a product with its own dose of fad, almost dogma (let's do everything in UML, ontologies, sequences, deployments; precompile it, compile it, run it...).

I found it to be a pain as a student (it clearly was a fad at that point), but every time I go back to shipped code in mainstream paradigms, I understand why people went this way. It's as boring as intractable. We don't want to code at that level, we want abstractions, but these paradigms didn't help so we needed diagrams. And it's an offspring of OOP mostly which helped reducing cpp-like complexity but not for free.

IMO UML boils down to a visual type checker. We can layout things more efficiently than with linear text, and can appreciate the relationships between parts. But in a way, that's what a type checker does. I remember never needing a diagram (for medium single person programs that is) in Eclipse since it could look at the whole system for me and show contradictions or suggest options.

I'm now very regularly tempted to do things with a bit of empty interface logic checking, FP-ish minded. You can still write this as text, and as long as it the types flow logically it's OK.

ps: this was also influenced a bit by posts like these https://www.google.com/search?q=f+sharp+uml


UML emerged out of the whole CASE (Computer Aided Software Engineering) movement. (Now there's a term you don't hear much any more!) Things were never well standardized and UML was an attempt to bring some sanity to the whole undertaking.

I used to work on a CASE tool early in my career. I was always struck by the fact that we never ate our own dog food; that is, we never employed the tool we were working on to guide its own construction. This was the first time my eyes were opened to the fact that perhaps there was a lot of junk being built :)

CASE itself I believe was an attempt to replicate for assembling bits some of the benefits CAD/CAM was bringing to assembling atoms.


Yes, CASE grew out of CAD/CAM. There is probably a whole field of anthropological work to be done as to how this came about and why nobody talks about CASE any more.

Although the latter is partly because the idea of doing 'SE' without the 'CA' is now inconcievable, even to senior management.


But it's a natural and beneficial (wondering) thing to do. Leveraging automated logic to reflect on other forms of automated logic (code).


I never connected CASE with CAD, I stopped at Booch's history.

Same about dogfooding. When I realized RSA wasn't (at least when I was working on it) developed with RSA or any UML I felt weird... Doubly weird since other tools like IBM Jazz (team collaboration) used themselves to ensure a certain dose of value.


UML, if you don't want to generate code from it, is nothing more than boxes and lines. You just use a common set of lines and boxes, so that anybody else who knows about UML understands your doodles.

Nobody forces you to use software to draw UML diagrams and nobody forces you to include every aspect of your objects in the UML diagram. The basic idea of UML is pretty sane, many people just overdo it.


Right. The problem is that formal UML diagrams tend to be part of formal documentation - i.e., outdated from the moment they are saved to disk (unless they are used for reproducible code generation, in which case.. good luck).

Informal UML diagrams - dynamic box-and-line relationship diagrams scrawled on a whiteboard where one arrow has been drawn in extra thick to emphasize a point; sequence diagrams where one colleague has drawn the sequence arrows as they work today and another has scribbled over the top the arrows as they should work in a different dry-wipe color; those are an appropriate use for "sort-of-UML" - as tools in rapid communication of ideas. My phone's full of photos of that kind of UML. But at that level of formality, nobody should mind if you get the open or filled diamond arrowheads wrong, or you use arrows for one to many relationships instead of inheritance, so long as everybody working on the diagram understands what is meant in that moment.

UML is a formal standard for back-of-the-envelope doodles, and that is exactly as ridiculous as it sounds.


I found class diagrams quite wasteful as well, you need load of time just to fill in redundant details and any issue you hit in development (i.e. you got the initialization order wrong on a not so well documented third party lib) is a mess to backtrack.

however, I found that a good sequence diagram here and there and a deployment diagram could really ease up communication when comparing the critical points of two or more different solutions - if done at the right level of detail.


(Disclaimer: I'm not UML/architect expert)

I get your opinion from a programmer point of view. However from the big picture point of view, either from the architect or from the client (if she (even partially) gets UML), it could be really useful.

E.g. let's consider working for a large financial institute, designing and/or implementing very difficult workflows / algorithms what would you use instead? In my experience most of the clients don't take the time to read half (if at all) of the agreed spec, not to mention understanding. In that case an activity/state diagram really helped a lot.

And on not versionable: you are right only to an extent (e.g. exported Visio diagrams to JPG...). However there are tools/methods, which can be versioned (e.g. generetaing UML via Graphviz/dot, and AFAIK Enterprise Architect supports versioning too).


"..I'd rather outline the major components of a system by drawing (on real paper) simple boxes and lines, or write the code that implements the system."

I understand you, but the problem of simple drawings is that is not a common language broadly understood.


I've found that diagrams generated from code or APIs can be useful sometimes - Graphviz is great for that. But I never really go beyond "simple boxes and lines" myself when sketching things.


When I left university I was convinced that software would be better if more projects would use UML. Then I've learned that UML didn't help in many situations and I stopped more or less using it. But from time to time UML is a very useful tool. Recently I worked on a system with a very complex data structure and UML really helped us to order the mess and to communicate with other parts of the team.

Another good use case for UML is the visualization of complex flows in frameworks.


I gave up on UML for the exact same reason about 6-7 years ago and have written over half-a-million lines of code in three different languages since then. Never missed it.



In some cases it can still be useful. E.g. Sequence Diagrams are crucial for figuring out how you are screwing up when designing a network protocol.


"I've generally found UML to be a complete waste of time."

This!




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

Search: