Hi All!
I'd like to know your opinion on whether UML is still needed in developer's daily work.
If you're curious why I'm asking about UML plea...
For further actions, you may consider blocking this person and/or reporting abuse
UML is definitely worth learning, and there's a lot of good stuff in there when used sparingly. As others have said already, you need to watch that the diagrams don't become out of date when compared to the source code. Also, and I have no empirical evidence to back this up(*), very few people seem to use UML nowadays, so you have to take into account the potential learning curve of your team members. A couple of recommendations ... (1) ensure that everybody on your team understands the abstractions you are using on your diagrams (be careful with terms like "component", "module", "service", "subsystem", etc) and (2) ensure that every UML diagram has a key/legend to make the notation you are using explicit.
This is a pretty large topic, so a couple of starting points you might want to take a look at are my C4 model (this is an abstraction-first approach to diagramming; compatible with UML) and my Visualise, Document and Explore Your Software Architecture talk that looks at diagramming from a number of different perspectives.
(*) I've run diagramming workshops for over 10K people around the world, and most of what I see is "boxes and lines" rather than UML
Regarding empirical evidence, you may also have a look at my research :-)
sbaltes.github.io/projects/sketches/
Section 3.3.3 of my paper on "Sketches and Diagrams in Practice" describes that most sketches and diagrams in our study were rather informal and only 9% of them were classified as "pure" UML diagrams.
I've look on your research. I like your poster: Sketches and Diagrams in Practice very much. It would be great if you could attach it in this discussion. I think it mainly agrees with this discussion participants opinions :)
Thanks :-) I hope this works:
Thanks a lot I'll look at your research.
Hi and thank you for your replay. I aware that other developers which I'm working with should understand me and my language which is in that case UML. In my opinion the biggest advantage of UML is that it is understand by developers accross companies and technologies. I can send a diagram written in UML to 3rd parties and I will be understand (or I hope I'll be :)).
I'll look at C4 model and video from your presentation.
Thanks, you're welcome! Yes, the biggest advantage of UML is that it should be understood by people in different teams and organisations, but that hasn't turned out to be the case unfortunately. As with any notation, it's easy to create diagrams that are meaningless. I always point to these examples ... I'm sure they are "correct" UML, but I don't really understand what that diagram is saying, what the responsibilities of the "components" are, etc.
That's true that with UML we can easily create meaningless diagrams or diagrams which are only understandable for UML experts rather than regular developers. In general we should avoid that. I've been working with one architect which has created such a diagrams. They were hard to understand but I can in easy way generate C# classes based on those diagrams. That was quite comfortable :)
I've just seen your presentation on OpenSlava 2017. It was really nice and descriptive. I like the approach to treat diagrams as a map with a different level of details on it.
Things which I'll keep in my mind:
always add a legend to a diagram
I hate when people are using acronyms, symbols etc. which can be confusing and/or be interpreted in many of ways
create documentation which could be read in 1-2 hours to get an introduction into project
I agree that 1-2 hours should be enough to catch big picture, and should be enough for reader to know where to look in code for more details.
An extra thought. You said that 1 on 10 people knows UML. I'm just wondering how would a group consisting of 10 people who know UML handle with your exercise with diagram creation and interpretation. Would they be confused or would they read it slightly? It could be very interesting and funny experiment.
Once again thanks for your opinion in this discussion.
Thanks again, I'm glad you found the talk useful. :-)
Yes, I've run my diagramming workshop for teams that have told me they "use UML for everything", and surprisingly the diagrams they produced were the same confused collections of boxes and lines. These diagrams were not particularly UML either, although a few UML notational elements (e.g. interface "lollipops", or the "cup and ball", etc) are often thrown in for good measure. Although I ask groups to use pen and paper, some insist on using electronic tools because they "want to get the UML notation correct". This generally doesn't help either, because you get diagrams like this, which are just meaningless.
In summary, even when I work with teams that "use UML", after some discussion, it turns out that most of them only use class and sequence diagrams, which isn't sufficient for describing software architecture (IMHO, of course). I've seem a very small number of people take a "pure UML" approach to my diagramming workshop, but that tends to make matters worse because nobody else understands the notation being used.
A big problem here is that it's really hard to find a good set of example UML diagrams based upon a real case-study, so everybody's view of UML is wildly different. This again comes back to abstractions. If you can figure out what abstractions (and, therefore, levels of detail) you want to show, the rest falls into place easily. This is why the C4 model exists, and why it's an abstraction-first approach.
I am dearly interested what you think about the AUTOSAR specifications if you mind to take a quick look at them. I'll hold back my opinion on this until I've heard at least one educated judgement from someone else.
I've been pointed to AUTOSAR before, but I don't generally work in the automotive industry, so I'm not sure I can offer much in the way of an opinion about it. I hope there is a good amount of benefit given the specification is 270 pages though. :-)
Some other verticals have their own domain-specific modelling languages too; embedded software immediately springs to mind, where I've seen domain-specific "architecture description languages" used. In my experience, even these teams (and those creating comprehensive documentation for regulatory purposes) are seeking ways to improve their communication. For some, UML is a good fit. For others, not so much.
Sequence diagrams for interaction and activity flow diagrams for logic. The rest, not so much. Aside from that I also find use in ER and DFDs. One of the greatest uses is when I want to clarify things for myself.
I hear this same response from a lot of people. I think UML is a great attempt and standardizing modeling and diagrams. Its not perfect, and its huge, but I think worth learning especially in big complex software systems. If you give 10 developers a task to diagram something, and all 10 will have something different, some may be better than others. And you would have to learn what each of the 10's modeling shapes/components meant to that author, every time, instead of already knowing by learning and using UML once.
In big software systems in the enterprise. it makes a lot of sense to make a document/model/diagram that can be read by everyone, and is a proven way that works by software experts to describe or model something in that system using visual shapes/aid. And UML can be extended, its not perfect and doesn't always fit. But I definitely think its worth the time to learn and use, so everyone can be speaking the same language when it comes to modeling.
Hi, Rafal.
It's a good subject to discuss. I've some opinions about it:
I think UML is a good way to understand complex domains and software architectures. It provides a fast and top-down vision of the problem. However, I don't like it for documentations, class modeling or other complex and variable operations that needs to be maintained. Programmers don't like to maintain documentation, diagrams or any other artifact that isn't the code base.
I like to use UML for fast operations, for example, when i'm working on a complex task and I need to understand an implemantion that needs to be refactored.
I hope this helps.
Regarding the point of maintaining both the documentation and the UML diagrams, aren't there program which will autogenerate/update the UML based on code changes? As well as generate the entire "scaffolding" of classes and functions specified by the UML (can't remember that right word… boilerplate code?)?
If yes, do they work in practice, or are they more trouble than the benefit they provide?
In my previous work I was using Enterprise Architect (EA). This tool has ability both to generate code based on UML class diagram and to generate class diagram based on written code. My team went even further and one of us has written a custom plugin to EA which produce documentation based on defined template. Generated in such a way documents were sending to our customers and subcontractors.
Documentation was generated fully automatically. It looked nice and its update was super easy. I only needed to update documentation in code. Unfortunately this plugin didn't apply to behavior diagrams. Of course developer needed remember to update documentation in code and generate the documentation.
First thank you that you as an author of first comment :) and yes your comment is very helpful.
I'm the same opinion as you that UML can help with splitting complex task into smaller. In my opinion it's easier and faster to detect come issues with UML. It'll save developer's time in the future.
I agree that creating and updating documentation in UML is painful. I think that depending on details level we should use UML or unit tests and comments in code as documentation. (By the way I'm a big fan of unit tests). As an example, interactions between two system or system components, architecture of used in system components should be done in UML but implementation details should be documented via a unit tests and comments in code.
Agreed.
I use UML diagrams for top-level documentation, like to show how systems are related to each other. And I find it much more practical to document low-level stuff with the code side by side, in the form of unit tests and code comments, because this way its easier to find the documentation when you need it most and more convenient to update. I do use UML diagrams for low-level stuff on the occasions I need to discuss really complex logic with my colleagues before coding starts.
And for databases, I always design the database on ER diagrams before writing the necessary migration queries, because it is easier to visualise how different DB designs might affect read/write efficiencies.
I think all software professionals should learn to read and write UML diagrams. But when and where they will find it appropriate to use is subjective to the nature of the project (outsourced vs. in-house, waterfall vs. agile, cost of installation / updates) and their team culture. Traditional software delivery business models would favour the use UML diagram more.
The biggest problem with UML is that it focuses on codifying relationships and attributes, rather than on making diagrams that are easy to understand at a glance. If I have to train people to read and decode my diagrams, they lose most of their value. This "hidden legend" separates me from my audience and furthers the stereotype of the Architect living in his own little world.
Instead of trying to pack a ton of information into a single diagram, I prefer to have multiple simple diagrams. Present the big picture in one diagram, then zoom in on a specific area or relationship to provide more depth in another diagram.
I do think that being trained on diagramming is worth it, and having a standard can make for better quality training, but assuming that all engineers will have been trained is folly.
I've been using several UML tools (Rational Rose, Together and Enterprise Architect) and I agree with you 100%. Class diagrams are a must to understand a complex hierarchy at a first glance, it's just so much harder just by reading the code. Sequence diagrams are fine if the algorithms are not very complex. Use case are probably the less useful. You're right that these days few people do not like them, I guess it's all the agile hype and "code is the documentation". If UML did not exist, another graphical notation should. As they say, a picture is worth one thousand words.
I like this:
a good indisputable argument in this discussion.
In reality I believe that UML is rarely used in any workplace and I assume it is related to an agile environment vs a waterfall way of thinking. Waterfall encourages UML as you can spend days and weeks designing the whole project in diagrams and trying to explain every aspect in the application. On the other hand in an agile environment where the iterations are so fast you barely find the time to design uml diagrams and evaluate them as the requirements as constantly changing by the business stakeholders. The only place where I used UML in the past extensively was in a university.
What I find useful even in an agile environment is the use of sequence diagrams to understand the complexity of some systems. But class diagrams, I don't see them in any real project scenario whatsoever.
So we can assume that Agile is killing UML :) I'm just kidding. I agree that UML is useful when we're working in waterfall (as I had in my previous work).
Something I miss in Agile is that developers are forgetting about documentation creation at all. They are excusing himself
And on the end of a day we haven't any documentation.That approach is in my opinion wrong.
Yes, although it sounds very stereotypical, I see this all the time where "agile" teams don't have any documentation (often because they claim that the code is the documentation, which it isn't). This is simply a misinterpretation of the manifesto, and agile in general.
I still see jobs on Cobol or other technologies, so probably there are ppl still using it. UML has an overhead and a small scope, but I like diagrams in general:
UML was ultimately a flop. Back in the nineties and early 2000s people believed in things like model driven architectures and such things. You would go and develop diagrams primarily and then generate your software. Naive, I know (seen some excruciatingly misguided applications of MDA back in the day). Then agile happened, became the norm and stuff became iterative by default. People started focusing on shipping working software regularly rather than diagrams of software that don't survive the first round of refactoring (i.e. the next sprint) or any form of scrutiny by an actual developer. That's just not a thing in a rapidly evolving software project.
What's the point of having complex artifacts around that lack the ability to co-evolve with your software? There is none. End of story. Basically UML got demoted to something you scribble on a whiteboard or put in some documentation that never gets updated or appreciated. At best you get some generated UML straight from the source code for staring at if that makes you happy. It's an aspirational thing at best in most software projects and necessary but pointless bureaucracy in some places.
So, is UML relevant? Probably still a little bit for some. If you are going to draw any diagrams on a whiteboard, they might at least be as little UML-ish; why reinvent a new way of drawing the same stuff. At least being able to read/glance over the damn things is mildly useful, occassionally. Although, I must say it's been a while since I looked at a UML diagram and found them insightful/enlightening. That just doesn't happen to me a lot. I don't encounter them that often to begin with and when I do they tend to be either extremely high level or just documenting the bleedingly obvious either way.
I think there are a couple of issues with UML, that prevent it from being used more often:
I'm working on a tool named Sourcetrail, which takes lots ideas from UML, but puts them into a fully interactive user interface for source exploration. All diagrams are generated on the fly. Watch our intro video.
Thank you. Sourcetrail looks nice. Unfortunately this tool hasn't support for my main programming language which is C# :(
I want to avoid situation in which I'll send to my customer diagram written in tool he or she doesn't know and doesn't want to learn. But maybe I'm wrong.
"I was thinking that nowadays nobody uses UML in daily work."
Your manager is right, at every meeting / project I did ask the question: "do you use UML or BPMN ?" nearly anybody answers yes even in big corps where official methodoly requires documenation with UML diagrams :)
Bill Gates said: 'Banking Is Necessary, Banks Are Not' I would say 'Modeling is necessary, UML is not' ;) Unfortunately developers do modeling with Framework which is not a rational way to do, some part of Business Modeling are now even done by Graphics designer, which is not rational either.
So I have looked at some other fields I know because I'm an engineer I know the automation industry, they have a specification and modeling tool named grafcet that is very simple, and I'm experimenting with it for now, after many months, I'm now sure it can replace UML, BPMN and many more easily with both better mental mapping for Business and direct mapping with code for ANY programming language high level or low level like assembly.
I'm not a big user of it, but I find sequence diagrams to be a great help in keeping the (RoR) design focused on simple, well-named objects with clear responsibilities, and well-formed messages and data passing between them.
In a previous career as a data warehouse architect I was a big user of data flow diagrams -- they were all I needed for ETL documentation.
I've been coding in a subset of UML, xtUML, since 1993 when it was still known as Shlaer-Mellor modeling.
UML is much more useful when the diagrams are executable at the analysis level and directly translatable into code, but you have to understand what is worth modeling in UML and what is better left to existing code libraries or other tools. e.g., never try to model mathematical algorithms in UML, or modeling strncpy() isn't going to give you anything that strncpy doesn't already do.
One of the barriers to entry used to be the cost of the tools, but cheaper tools came along. Now the only xtUML tool being actively maintained is free and open source.
Much more information is available at xtuml.org. Tool download and training is available there.
Hi Rafael,
my answer for developers is yes. I think we need tools that enable us to automatically generate and update visualizations of the code we work with. Doing this work by hand needs to much time and leads to too much errors.
We also need techniques to handle such diagrams as typical applications contain very many objects.
I find diagrams that show dependencies very helpful, but I did neither found the correct diagram for this in UML nor a tool I can use. Especially as I work with SAP ABAP.
After I learned from the Moose platform (moosetechnology.org/), I developed an extractor and a Software Exploration tool for everyday usage in my project, SAP2Moose and Moose2Model. The second can also be used for other languages. Generating a new diagram or updating an old diagram to changed coding takes currently a few minutes. This is much faster than for diagrams I made by hand, I often spend days for such diagrams.
After one year of development I use this tools now for a year in my concrete work as developer (not as architect). Before, I often felt lost in the coding and lost a lot of time searching or trying to remember where I am or where I was. This happens now much less of the time and especially in cases when I cannot use this tools.
There are not many Software Exploration Tools in active development currently, but I see a lot of potential in developing and using such tools, as they will become better and better over time.
Another example of a Software Exploration Tool is Sourcetrail, it can be used for Java, C and C++.
My impression is, that all this tools do not restrict themself to use UML for their diagrams. My impression is, that UML is powerful to design new software. But software exploration tools aim to support developers during their work in real code. Code which may be well developed, but too often this is not the case. I have the impression, that there is yet not enough understanding of how diagrams for this use cases should be made. I also see no urgent need for a standardization here, adding a legend should be enough for now.
Best regards,
Rainer
PS I evaluate currently to enhance the tool to be added to Eclipse and plan to keep it open for all languages
Thanks for your advice. I'll look closer to that tool in the nearest future.
1: UML is bad and should not be left in a room alone. 2: UML does not scale.
About 1, some UML diagrams (most notably class diagram) do offer a usable way to enhance a message. It should only be used as a supportive image to an explanation. UML is not good it communicating the message by itself, a lot of information is encoded (vaguely) in the diagrams. It is not well understood by all. It does not translate well into all environments. The danger of including an UML diagram is that people will not read the supportive texts, and thereby not implementing it correctly. But I still used UML because it is better than nothing.
As for 2, as your architecture starts to grow the usability and readability of all UML diagrams starts to drop rapidly. The result will be worse than it using UML to begin with.
Before standing my point, two things.
1) nowadays as a .net developer you can work first on your design projects, then you scaffold than into classes and then using code first and entity framework you have you db physical schema done as well, and this is so cool.
2) we are in a world where those who work on waterfall cannot think of coding without some sort of documented design (where I believe a unified criteria is so good to have) and people that after misunderstanding agile strive to avoid any kind of documentation.
Now, on my experience it depends on what you are working on. If I need to solve a simple problem with a CRUD, I will probably start writing code. Most likely to neither write a unit test for it. If I'm working in a (for example) calculation engine, I will definitely start with a class diagram. If I need to get in place a workflow that is hard to see, I will start with a sequence diagram. To my point: Design is something you do because you need to. I find senseless to do diagrams just because. When you do it in sessions, getting the team together looking for a solution for a hard-to-solve problem it will be also fun.
I agree that we need to use dedicated tool for particular job. In my opinion UML isn't golden hammer but it can improve my work (I hope :)).
Be the way I like your example with Code First approach in Entity Framework.
Aligned with your thought. There's no silver bullet. We need to be smart enough to use it on our benefit and on leaving it aside when we have something better to use (expandable to frameworks, tools and methodologies ;) )
As long as diagrams are deemed an effective way of communicating a system design, it makes sense that there are standardized conventions for drawing them.
The problem is that UML does seem to have a bad rep. I think UML is often conflated with just class diagrams or seen as being too "enterprisey" and developers don't realize it's value in the right context.
I've the same opinion. Most of people which are complaining on UML simply didn't work with it.
You may see also the comments to the Tweed to this post: twitter.com/ThePracticalDev/status... for instance the answer by Simon Brown who maintains a tool to make diagrams for architects.
Thanks. On Twitter is a hot discussion too. I'm glad to see that :)
Having a common modeling language is a good thing. I don't want to have to explain my particular modeling notation to every developer reading what I produce. Having well-defined languages is a good thing. Of course, UML isn't a silver bullet. We have many, many programming languages. There's no reason why we can't have many modeling languages as well. But having well-defined languages instead of everyone using arbitrary symbols is a good thing. UML, as a language, is pretty comprehensive. I'd recommend learning it and using it where appropriate to talk about systems.
Martin Fowler wrote about four of them - sketch, notes, blueprint, and programming language. UML is a rich language, but that doesn't mean that you need to use every single feature it provides. Pick and choose appropriately and make your models at the appropriate level for the target audience. But stick to the rules that the language provides so that people can easily understand the notation used. Personally, I don't believe in UML as a Blueprint as I believe that code is the representation of the design of a software system. I haven't seen or read about any huge successes with UML as a Programming Language, either. However, UML as sketches or notes make perfect sense to me.
Understanding architectural viewpoints and perspectives is a good thing. To this end, you should learn other modeling languages. I haven't used it in actual work yet, but I'm interested in Simon Brown's work on C4 Modeling for Software Architecture - this was mentioned elsewhere in the comments. For database-intensive systems, Crow's foot or Chen's notation for ER diagrams is useful. I've used the IDEF modeling notations, too, with decent luck. SysML is a good compliment to UML for systems engineering. There are special symbol sets for Cisco or AWS networks. Depending on your audience, some or all of these can be used for different models of your system. I also believe that most modeling languages can have the modes that Martin Fowler described.
I think this may have been a little scattered, but it's my general take on the usefulness of UML.
Thanks for your opinion.
I agree with you that UML isn't a silver bullet. I thinkt that creating class diagrams consumes a lot of time and gives us just a litte benefit and force us to update those diagrams after single change in code which could be frustrating :( On the other hand I love sequence diagrams espesially when we are going outside current domain. To sum up my plan is to get to know all UML diagrams and possibilities and apply those which will be most beneficial for my in my daily work.
I plan dive deeper into Simon Brown's C4 model. On first glance it looks nice and promising but I need more time to investigate it.
i was taught uml at school, and With my 1 year experience in software engineering,I usually use it to design class diagrams and uses cases diagrams !!
But i realy like the class diagram because i Use to for building databases structure of an app using ORM frameworks.
I had UML at university too. To be honest I regret that I weren't listen carefully during UML lessons on my studies. But I'm thinking now is time to fix my inattention :)
I cannot believe you've never used UML.
Didn't you read the "Design Patterns", by GoF? It is full of UML diagrams.
Didn't you generate a documentation from code, using Doxigen or similar? It generates the UML class relationships.
Didn't you use MySQL Workbench or similar software? It shows the relationship between tables like UML Classes.
Haven't you explained something with a flow diagram? Sure it is very similar to UML diagrams.
Really, UML is just to standarize some kind of usual charts to give a common language for everyone. Maybe you are not able to create one without any mistake, but surelly you can read an UML diagram.
For example, it may be cool to describe a pattern, like the Abstract Factory (sourcemaking.com/design_patterns/a...), or a workflow represented by an Activity Diagram, or Use Cases to show the desired behavior, etc.
I suggest you to try plantuml (plantuml.com) to start explaining your presentations, and surely you will learn how to use it quickly.
Many people use (or at least read) UML but don't know it. For example, sequence diagrams and class diagrams have been around everywhere I ever worked. But people forget that they are "UML".
In over 20 years of professional programming, UML was relevant for about 6 weeks of that time for me. (and never in production). I've implemented, designed, maintained or otherwise built successful products and services without ever needing UML.
Are you saying in 20 years you have never found it necessary to model or communicate system designs with diagrams or that you have not used UML as the standard for such diagrams?
Used flowcharts, boxes with arrows, post its. Salt cellars. Sequence diagrams. Good old fashioned collaboration. Not UML.
All of which are covered by UML
The answer for every question of this type is always "Yes, this stuff seems dead, but it has actually found a niche somewhere". And then there's the thing with programming. "Is it worth the while to know ?" begs the answer "Yep, if you've got infinite time and swap jobs often you might find yourself in a situation where it might prove useful".
However, there is always a limited budget for learning new stuff and university courses and syllabi are also limited, so you have to optimize for the most frequent technology, that being probably *not using UML but agile technologies such as Kanban or SCRUM. So
In my daily work I'm using scrum methodology. I think it's great but I'm still missing UML :( In my opinion it is hard to come into project especially big one due to lack of big picture of it. I agree that working on particular features which are well defined is easy and it doesn't required UML, but it was hard to me to understand how all things are working all together.Personally I think that a diagram (not necessarily created in UML) would be in this situation very helpful.
I was taught about UML at university. It seemed like a nice priciple, but way too verbose and complicated.
Ive used bits of it in day to day software design, but I sketch out what's in my head and work from there.
I honestly don't think UML has improved my ability to programme.
Never used it so far in my career (~17 years since first production web app). I probably had to use it in school. But it has never been a job requirement. I have researched it and played with it on the job. But nothing that made it into source control or deliverables.
Rafal...Great post even if I am nearly 2 years late to share.
Over the years as a software architect consultant, I have discovered that UML has become "nearly" obsolete as a standard tool to communicate architecture. In the early days (I am dating myself), we used UML to demonstrate an understanding of the business requirements, and then to share intent with software engineers. It also served as documentation. Today, with Agile, Scrum, storyboards, and the like, it appears the input energy required of UML doesn't warrant what it can output.
Today, we use UML for new client projects for the purposes stated above, to then feed into our project generator to create the first pass of an application and all it's other bits. We also use existing UML created for legacy apps (eg: JEE and 4GL apps, etc..) to assist in generating the groundwork in app refactoring.
I am not sure it will see a revival, but we have discovered value in UML when it serves as input to a larger more valuable output.
Hi Steven,
Thank you for your comment. I agree that the entry threshold is often too high, and sometimes using a UML diagram is simply an overkill.
BTW I'm glad that almost two years after the post has been published is still alive 😉
There are tons of videos about programming. Similarly, sometimes when I open news articles they lead to YouTube videos, which I find frustrating. I want to read.
Why do developers and news organizations produce content in video form when I'd rather read? Because while I prefer to read, some people prefer to watch videos. We're all different and we process information differently.
UML is useful if looking at diagrams of code helps you understand code. Otherwise it's useless. I'm in the second category. If I want to understand code I'll look at the code. If I need an overview I'd rather read a well-written paragraph or two.
Why do we need to understand code? Isn't it primarily so that we can modify and maintain it? If we were never going to change it, why would we need to understand it?
There's only one place where we can communicate intent in a way that doesn't become inaccurate as soon as we change the code, and that's in the code. If we're not looking at the code and trying to understand it, then we don't need to understand it. In that case, why do we need diagrams? If we create diagrams but don't make the code itself understandable, is it possible that the diagrams were wasted effort?
I'm not saying UML is bad because I'm sure they're helpful to some people. But I'm not likely to look at them and I'd rather put my energy first into making the code understandable, and, when necessary, describing it with written words. I don't know if the next developer reads UML diagrams either, but we all read.
Not a fan at all. I would prefer a statechart, flowchart, or just about any other diagram. UML's popularity reflects it's utility.
I've almost never used UML but now I feel like I should start
UML has always been on my TODO list.
I've decided that it is the right time to take it from my list, learned it and use it.
Of course I'm encouraging you to start use UML :+1:
I definitely use UML when drafting a design for code. It's good to be able to get constructive feedback on the code before actually writing it!
Thanks for your opinion.
I totally agree that founding a issue on early phase will save a lot of time and money. There is a huge amount of articles describing that:
Constructive feedback is always invaluable and it will improve our code/architecture/thinking :)