While I'm okay with the general approach of system design, I'm opposed to anything getting to the detailed level of UML.
I believe it's a broken notion that there is a useful description of systems that can both be read at a high-level and directly converted to technical implementations.
You're also doing over-design and this ends up slowing down project process, and paralyses participants by preventing them from deviating from an agreed upon design. Technology driven systems need to be highly flexible during develpoment or face an increasing risk of failure.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
UML and its relatives have a point if you're throwing specifications over the wall to another team you can't interact with directly (or vice versa). Then you really do need to have things laid out with that kind of detail.
If you're throwing stuff over a wall then your system is doomed to failure. I know this kind of spec and hand-off approach was popular at one point, but it's basically a failed development strategy.
You need a two-way communication with the teams involved in the development of a product.
UML is attempting to patch a fundamentally flawed approach.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Sure, it's flawed if not outright The Wrong Way To Do Things, but that doesn't mean it's not still happening for reasons which are often outside developers' control. And if you want to have any chance of getting something usable out of that kind of process, you need to set stuff in stone.
When you let people design something on their own, they usually draw only boxes with lines. My point is that, when refining your design, you need to use the same convention to describe things, a simple convention that everybody understand and UML can be the right choice for some teams.
A better approach would be to have a human readable format that helps you to make your design (this format could generate UML diagrams) and create also your system at runtime (this format could generate your classes and components). This is the approach I chose for my project (I will develop that in another post).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I'm okay with the general approach of system design, I'm opposed to anything getting to the detailed level of UML.
I believe it's a broken notion that there is a useful description of systems that can both be read at a high-level and directly converted to technical implementations.
You're also doing over-design and this ends up slowing down project process, and paralyses participants by preventing them from deviating from an agreed upon design. Technology driven systems need to be highly flexible during develpoment or face an increasing risk of failure.
UML and its relatives have a point if you're throwing specifications over the wall to another team you can't interact with directly (or vice versa). Then you really do need to have things laid out with that kind of detail.
If you're throwing stuff over a wall then your system is doomed to failure. I know this kind of spec and hand-off approach was popular at one point, but it's basically a failed development strategy.
You need a two-way communication with the teams involved in the development of a product.
UML is attempting to patch a fundamentally flawed approach.
Sure, it's flawed if not outright The Wrong Way To Do Things, but that doesn't mean it's not still happening for reasons which are often outside developers' control. And if you want to have any chance of getting something usable out of that kind of process, you need to set stuff in stone.
When you let people design something on their own, they usually draw only boxes with lines. My point is that, when refining your design, you need to use the same convention to describe things, a simple convention that everybody understand and UML can be the right choice for some teams.
A better approach would be to have a human readable format that helps you to make your design (this format could generate UML diagrams) and create also your system at runtime (this format could generate your classes and components). This is the approach I chose for my project (I will develop that in another post).