Is the UML graph a good way of showing your ideas/ write documents of your project? [closed]

Question

I am trying to lead a team of developers to convert my ideas as a CEO to real products. As my company is a small startup with low budge, and I am also a mediocre developer, I decided to learn system architecture and try to do it as a software architect by myself.

But I don't know how much abstraction or detail is most efficient? For example if I want to define tasks in an Angular project, is it a good way to draw UML graphs?

I also have a problem with documenting the project. I am looking for a way that I can combine these two parts together. I mean the system architect will also be the system document. Is it a good idea in your experience?

I am glad to hear related ideas/experiences about the problem?

Answer 1

It sounds like you intend to micro-manage. That's not a good idea, especially when you're a mediocre developer.

Start with requirements analysis and most importantly discuss your ideas with the developers (talk, not diagrams). As the CEO, your job is to define goals, not dictate steps.

Make sure you listen to advice from more knowledgeable people in their areas of expertise. A good part of successful management is knowing when to stop and let others do what they do best instead of interfering with their work.

I know this doesn't answer your question about how to write down and document, but I feel that answering those questions would not really help solving the underlying issues.

Answer 2

UML diagram types which can be useful for managers to communicate their business requirements to their development teams are:

• Use-Case diagrams explaining how end-users should interact with the final product.
• Activity diagrams describing the workflows of end-users. But consider leaving them to a professional UX designer, if you have one on your staff.

Most other UML diagrams document technical low-level implementation details which should really be left to those people who are actively involved in the implementation.

There used to be a time where you had a senior developer (a very experienced developer, not someone whose main skill is business management) drawing class diagrams, interaction diagrams etc. and then leaving the implementation of those diagrams to junior programmers. But this style of software development is largely antiquated in many organizations. Modern software development according to agile practices is a lot less hierarchical and expects developers from all experience levels to be involved in architecture decisions. Managers are expected to have a hands-off approach of providing goals, requirements and priorities to the team and then stand back and watch the magic happen.

Developers (in my experience rarely) use UML diagrams to communicate between each other or (more frequently) to document their decisions.

Answer 3

I think it depends a lot on your team. Every organization is different, especially small ones. Your question of how abstract should your guidance be is a good one, but has nothing to do with diagrams, and is literally "how abstract should my guidance be". You could theoretically micromanage every class and line of code. But typically someone leading from the top would simply provide a list of business requirements and the more technical people below you will figure out how to implement those. In a case like that you might provide your requirements as a a bullet point list, or UML Use-Case diagrams, or something else. If there was a manager between you and the coders, maybe that manager would flesh out technical details and produce lower-level design artifacts like swim lane diagrams etc.

So, are there other more skilled developers working under you? If it's basically you, a "mediocre developer", and a handful of underlings who are even less skilled than you, to the point that you feel like you can't trust them to design things better than you can, your business is going to be in trouble. Software businesses cannot succeed with a single "mediocre" mind. You need really smart people who have good skills. Either that's you, or you have to hire someone to delegate that thinking to. I don't want to beat you up, but to say "I'm a mediocre developer, so I decided to read some about architecture and do that", rings to me like someone saying "I made a birdhouse that was ok-ish, so I'm trying my hand at making blueprints for a water treatment plant".

Architecture is Hard, it is the culmination of abstract, hard-knock lessons gained over the years by very weathered developers. It involves:

• forseeing the technical snags a lesser programmer would not see, and handling them ahead of time in the design
• having a broad knowledge/experience with different patterns of structuring code and system components that preclude problems of scale/maintenance/coupling/reliability/deployment
• having wisdom (from experience) of making compromises in the otherwise "rules of design" and being confident in your Judgement of the balance of those compromises (what are they weighing against, what are the risks, etc)

Bad architecture means that the product will always be on fire, requiring constant shenanigans to keep it running, new code won't "fit" and will require papering over the intended architecture to get things done, devolving into chaos with the whole thing gradually becoming a structure of bandaids. It must be completely re-architected soon, once it crashes into the realities that an experienced developer/architect would have been an guard against. Rather than thinking architecture-first, you might consider a less formal approach of rapid prototyping each small functionality, and then stitching it all together after the fact. Creating a defacto architecture at the end. This is better than investing a bunch of personal resources into a (no offense) doomed-from-the-start dunning-kruger architecture. Excuse me for presuming your architecture will be Bad from the start (I don't know you so it's not personal), but that is my expectation from what you have said that you are taking this on yourself rather than delegating it (what a CEO does) to more skilled people I'm guessing you don't have on your team. In which case you would be better off having no pre-ordained architecture to fight against until you have some functional pieces in place, which you can then look at and determine how best to build some scaffolding for.

In fact I would advocate generally to be as flexible as possible, give your developers the requirements and let them test their mettle. They need to go through the crucible and develop skills. Let them fail at first and iterate on what they come up with. Have design meetings (you can participate), and a code review process, track the progress of component creation so it doesn't drag on forever and re-assess the roadmap frequently.

All of that said, I think UML can be great and is under used. There was a time when it was used very formally and that has fallen away, but it still stands as a pre-considered way of making many types of visual aids that are relatively easy to understand. These are helpful for having everyone on the same mental page about the target you are aiming at. My point is to say if you do go the UML route, don't be overly obsessed with "proper" UML. Just use whichever diagram types are useful to you for communicating a particular idea that needs clarity. And if you use the wrong type of arrow don't worry about it. It's just better than starting from scratch in terms of "how do I make a diagram that shows this".