Do industry professionals really use UML diagrams before coding?

I've used them only when I was discussing the architecture with other colleagues. But that happened less than 5 times in last 10 years.

@gitwithravish I imagine some do, but I’d consider myself an “industry professional” and have never planned using UML diagrams. The places I’ve worked at have used a more “agile” approach the planning and will work in sprints rather than trying to design the code upfront.

I've rarely used them, but a friend designs logic boards and they use UML (and the likes) all the time.

One of the reasons is the time needed to implement vs the time needed for the UML. Another is that UML diagram is easier to explain to the team.

I mostly do web stuff so when I need to do something I can create a quick prototype and then explain it to the team. Doing a complex UML will actually take me more time.

So UML is useful depending on you case. And sometimes they can be used to explain to team members outside the programing field how the system actually works.

@martinbean When I began to work with complex eCommerce projects, I saw that the source code contained a lot more than just controllers and models. For example, custom classes, implementation of interfaces, using the service container etc. I still find it a little difficult to "design" the software and implement OOP design concepts for complex problems.

How do you guys come up with the software design? Is it like you discuss it with the team or visualize it? Or is it left to the developers and the developers create the design as they are building the application?

Many application types such as supply, inventory, bookkeeping and accounting, income and expense reports, locistics with dispatch software, these are much the same techniques over the years. I just tailor to the companies custom needs.

It helps when you have worked in these industries with paper and pencil and file cabinets as well, which I have. It helps to understand what is needed in a program.

Basic bookkeeping has been the same for generations. But just requires some custom code, I.e., it's a little different for a non profit.

A good real life example, when I had to program for a non profit, I did not go to a forum. Rather I set up several in person meetings with a CPA to learn exactly what is needed for the IRS concerning this non profit, etc. So that's where I began.

I believe:

Do industry professionals really use UML diagrams

No. someone may flash one around, but probably not a programmer.

@gitwithravish Interesting question.I consider myself a professional, but I find myself in a role where I'm a sole developer for a mid-sized corporation. This has advantages of giving me incredible freedom to go whatever direction I feel is best, but of course, there are disadvantages - no delegation, more pressure to resolve issues, no one to cover on vacation, etc.. but I'm getting a bit off topic.

Since I work alone, I'm often curious about processes such as this. Personally, I've always found UML to be a waste of time. I used it once about 9 years ago, where it eventually ended up in the garbage. Having said that, as others have pointed out, I think it could have uses in other scenarios - such as trying to build a diagram that is universally understood.

Anyway, when it comes to your question regarding how software is designed... what I do for features, is I take a TDD approach, and write out the code within the controller. Once tests are passing, I then focus of refactoring to additional layers: interfaces, service classes, view composers, etc. I like try to stick with the "skinny controller" philosophy as much as possible. I rarely/never start off with a complex OOP structure; it evolves on its own thru refactoring, backed by tests. The more you become comfortable with all the different tools within the framework, and design patterns, it becomes easier to decide what direction to take. By using a MVC framework, it helps keep developers adhering to main conventions. There are just some of the minor ones that need to be worked out as a team.

A few examples of such conventions:

• Singlular or pluralized controller names (PostController vs PostsController)
• If using Blade, some like to prefix partials with an underscore, some like to make a sub directory
• Trait naming, such as always making them adjectives (Notifiable, Exportable, etc)
• Middleware to be defined on the route level or controller constructor
• Determine how strict the code will adhere to SOLID principles (i.e.: Laravel's complex models break the Single Responsibility Princicple, but many consider the convenience to outweigh the violation)
• As per above, some have no issues using ORM, others use the data-mapper pattern

The important thing is, that everyone understands what conventions are being used, and to remain consistent.

When I began to work with complex eCommerce projects, I saw that the source code contained a lot more than just controllers and models. For example, custom classes, implementation of interfaces, using the service container etc. I still find it a little difficult to "design" the software and implement OOP design concepts for complex problems.

@gitwithravish I currently work for an e-commerce solution vendor. In my two years here, “UML” has not been mentioned once.

How do you guys come up with the software design? Is it like you discuss it with the team or visualize it? Or is it left to the developers and the developers create the design as they are building the application?

As mentioned, we work in an agile fashion. There’s no “end” to the project, as it’s ongoing as the platform is always evolving to client needs and feature requests.

We have projects teams that will take feature requests and build them. I’m in an API team so we’re constantly building endpoints and refining the API infrastructure itself. We take discreet tasks, work out the deliverables, talk with other team members about what’s involved and the approach we’re thinking of, and then go ahead and start working on that particular piece of work.