Probable reasons for the non usage of UML in the software Industry

My interaction with the participants(ranging from 1-20 years of experience) shows, the following are the reasons for the non usage of UML in software companies. Some of the points might look rude but it is a sad reality as well.

Majority of the software professionals in India don't know about UML (as much as 90%).

For the professionals who know about UML... They really don't know why and in which phase should UML be used? In my programs almost 99% of the people believe that UML is used in the design phase and is used for designing systems. Professionals are greatly confused between analysis and design.

Managers consider Analysis and UML modeling as a waste of time. Their reasoning is "If one can create systems by writing code then why draw diagrams".

Young software professionals are more open and excited to using UML and doing it the right way, but the top management isn't technically sound enough to understand the importance of analysis and UML and hence they don't promote the usage of the same.

Unfortunately the most of the people in the top management are excellent man managers (not technical managers ) only bothered about parameters like,increasing the number of billable heads and the timeline there by increasing the revenues for the company while cutting the cost as much as possible.

Although UML is a set of standardized graphical diagrams for modeling the structural and behavioral complexities of any software system, A myth that UML is only meant for Object Oriented Programming Languages limits its usage.

Knowing the syntax of UML diagrams is a much simpler task as compared to knowing the best practices of using these diagrams to understand the structural and behavioral complexity of systems. For example knowing a syntax of a class diagram is a simple task while knowing and using the best practices of structural modeling using class diagrams is a completely different ball game.

Even UML Diagrams need to be designed for parameters like usability, extensibility and flexibility. If not designed for flexibility,

As UML Diagrams represents the structural and behavioral complexity of a real world system (mostly business systems). By the very nature business systems are dynamic and will continuously change which will result in changes in the UML Models as well. Unfortunately I have seen people drawing UML diagrams in such a unplanned manner that with every change, their entire diagrams needs to be drawn. Ask yourself, In a highly compressed project life cycle do we have the time to re draw the diagrams again and again? This is one of the reasons why the UML diagrams and the code goes out of sync with the passage of time.

The time taken to draw these diagrams is also critical as well. I have seen software professional take more than a days time to draw one UML diagram while for an experienced professional, it might be a matter of minutes. Ask your self if the engineers start taking more than a day to draw a single diagram then how long will the analysis phase take and how will the project manager accommodate the same within the project life cycle.

Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer