This depends on the company processes, business-level goals and challenges, and available resources.
UML
Fuzzy pictures of boxes and arrows. - Leslie Lamport
Unnecessary Management Lingo. - @iamdevloper
A language that was invented first and then people came around to try to get semantics. - Leslie Lamport
...
As usual, I think Lamport gets to the heart of the problem. Expressing things in an imprecise way can be of limited or even negative utility when it comes to actually nailing down code. However, a whole lot of decisions that need to be made in organizations that produce or employ hardware and software systems require knowledge, experience and communication outside of actual system design or selection.
Skip the architects, make the monkeys do the design. Have them vet it with each other, preferably in a formal setting with your entire engineering team. Everyone codes, and everyone architects.
This works if your people have experience and communicate well. Other times, not, like this example I had in London. CTO: "solve X really-stupid problem that my poor architecture that is not accepting of feedback created". Me: "OK, literally just-hired (some are first coding job ever!) type team: 'X is problem, Y is timeframe, Z is general proposed solution in data-oriented terms [always a good start], feedback?'" Result: Shit on walls, followed by gentle coaxing 'here's how to achieve Z, lets do it' and lots of babysitting. We got there, with just a little overtime, averted disaster on the high-penalty very large client contract, and still had time for beer. Conclusion: Guidance is useful, sometimes.
This depends on the company processes, business-level goals and challenges, and available resources.
UML
Fuzzy pictures of boxes and arrows. - Leslie Lamport
Unnecessary Management Lingo. - @iamdevloper
A language that was invented first and then people came around to try to get semantics. - Leslie Lamport
...
As usual, I think Lamport gets to the heart of the problem. Expressing things in an imprecise way can be of limited or even negative utility when it comes to actually nailing down code. However, a whole lot of decisions that need to be made in organizations that produce or employ hardware and software systems require knowledge, experience and communication outside of actual system design or selection.
Skip the architects, make the monkeys do the design. Have them vet it with each other, preferably in a formal setting with your entire engineering team. Everyone codes, and everyone architects.
This works if your people have experience and communicate well. Other times, not, like this example I had in London. CTO: "solve X really-stupid problem that my poor architecture that is not accepting of feedback created". Me: "OK, literally just-hired (some are first coding job ever!) type team: 'X is problem, Y is timeframe, Z is general proposed solution in data-oriented terms [always a good start], feedback?'" Result: Shit on walls, followed by gentle coaxing 'here's how to achieve Z, lets do it' and lots of babysitting. We got there, with just a little overtime, averted disaster on the high-penalty very large client contract, and still had time for beer. Conclusion: Guidance is useful, sometimes.