DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. We Do Not Use UML, We Are Agile

We Do Not Use UML, We Are Agile

Peter Verhas user avatar by
Peter Verhas
CORE ·
Aug. 16, 13 · Interview
Like (4)
Save
Tweet
Share
24.12K Views

Join the DZone community and get the full member experience.

Join For Free

I have heard this sentence many times, and I can not argue with it. These are two independent statements, and it is out of my scope to disagree. Your group does not use UML; fact. You are practicing Agile; again, fact. What is there to argue about?

A problem is usually implied by having “because” between the two statements. If you say “We do not use UML BECAUSE we are agile,” then there is a problem. Not a life threatening issue, but still something to think about. After all, agile is all about constant improvement.

UML is a tool that can be used on different levels, and it certainly can have a place in an agile workflow. There are several reasons why you might or might not want to use UML. My experience for why you may not want to use UML lists the same reasons as the article referenced above. You can see for yourself that these arguments are also very lame. All of them can be summarized as: “I do not know it, therefore I do not use it.” All other words are just psychological self-confirmation to push aside the bad feelings for the poor decision not to learn the right tool. Learning new topics is hard and people are inherently lazy. But this is what allows the experts to have a good job. Are you an expert?

This is even worse when people learn new things (like UML) but learn it half way and do not take the time to learn how to use it properly. Here I list a few examples of extremely bad UML. I personally have seen examples of each.

Intimidating Customer BA Using UML

Once I met a software company that created vast amounts of UML diagrams and presented the architecture to the technical people of the customer in this form. This alone was not a problem. The issue with this was that the technical people were aware of UML but were not knowledgeable. They just could not read UML and were afraid to admit it. They were afraid to complain about flaws in the design and the architecture documents went approved without significant feedback. This made the architect’s life easier for the time, but they caused significant headaches for the company in the long run. Even though the architecture design is the responsibility of the vendor, it is not without reason that they should be approved by the customer. After all, this is a cake baked by the vendor, but it is eaten by the customer.

Creating UML Documents for the Obvious

This was very similar to the first one. UML was used to impress the customer. There was a UML model created for each and every class, even the simple utility classes, components, communication models and everything. Then the UML tool created hundreds of pages; redundant PDF documents with all diagrams that were imaginable generated from the model. Fortunately the PDF never killed trees by being printed.

UML-Like Diagrams

I have seen many diagrams that looked like UML diagrams at first glance. On the second glance, you spot some strange notations and then you realize that different diagram elements are mixed in a single diagram, and they are used incorrectly. I have seen many class diagram elements used to depict relations between modules. What seemed to be inheritance by the notation turned out to be a communication from one component denoted as a class to the other by the intention of the designer. The complaint was, “our drawing tool does not support component diagrams”. OMG! Use a different tool then! Pencil and paper version 1.0 ?

We Know UML

“We know UML.” The problem was that the members of the team knew UML differently. They sketched something on the white board discussing the architecture but instead of doing the effective work, they soon started fiercely arguing on a specific line about whether it was composition, aggregation or a simple relation. C’mon. Focus on the real issue.

Conclusion

I'm not saying you have to use UML. I do recommend it though. Learn a bit but do not learn it to the extreme. Do not be shy admitting that you do not understand something. Ask for clarification. If you lack UML knowledge and you are the customer, ask the vendor to setup a workshop to explain the notation. If they say, “hey, this is UML,” you can bravely say, “Hey, I am the customer.”

Do not generate UML documentation.  The PDF files will be too huge. Whenever you create a document, ask yourself the question, "who will read it and what is the reason to read it?" If you are the customer, be strict and limit the size of the documentation you are willing to accept and read.

You may use UML like drawings, but do not be happy getting drowned in the mud. Learn and strive for the correct use. Other professionals will understand your diagrams if it means what it is meant to mean.

And last, but not least, use UML as a tool and focus on the work that needs to be done. Use UML and be agile.

UML agile

Published at DZone with permission of Peter Verhas, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How To Validate Three Common Document Types in Python
  • What Is Policy-as-Code? An Introduction to Open Policy Agent
  • Web Application Architecture: The Latest Guide
  • Why It Is Important To Have an Ownership as a DevOps Engineer

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: