How not to overdo it with the desire to design everything before writing code?

Question

Software design

I work in a relatively small company (two people on the backend, two fronts, two mobile application developers)
But the project is quite large and complex
. And now we are planning to develop a large piece of the project (it is almost comparable in volume to what has already been written in three years - a new service on the service) My
opinion was divided with a colleague
I say that everything needs to be thought out
He says: "Let's decompose into tasks and start doing. We'll figure it out along the way"
I joined the project later than my partner and, frankly, (I will short) do not like the way it is written. And I don’t want to aggravate, I want to do it in a quality way so as not to maintain shitty code for the next two years
But I'm afraid that the design will take too long and that this time will not be wasted. I even want to draw a UML diagram for future classes (well, in general, I should, the situation on the project is so-so)
I would like to collect the pros and cons of both approaches and find out if I picked up the "UML-brain" and whether I go too far with the desire to think through everything from and to before starting to write code

Answer 1

>don't like the way it's written
pfff what do you think, got into a fairy tale? you shouldn't like it, it's somewhere in the 25th place for business.
-----
To be honest, I have not heard at all that UML was actually used in practice for design (although the topic was once on the hype).
Well, yes, general ideas are sketched on drafts, the code itself can also be that draft for ideas, but this is just a draft.
=======
>"Let's decompose into tasks and start doing. We'll figure it out as the implementation progresses"
very smart and thoughtful approach. The main problem of inexperienced people is an attempt to immediately produce an ideal result in a vacuum, people who are more experienced know that this is not possible, and an attempt at an ideal design will only lead to overcomplication and worsen development, and instead of flexibly adjusting the solution to gradual refinements, you will strive to do everything fit into the framework of some first "ideal" implementation idea, based on the first perception of the task (which is often erroneous).

Answer 2

Design is helpful. Especially large modules. Do not spare time for it, this will speed up the development in the future, and the introduction of new features, when you will already clearly see whether there may be some problems with this feature or not. And after the design, you can already see what pieces to break into during development.

Answer 3

The design gives a "fastest advance map" to the first release.
Namely: the ability to competently plan the entire development process and correct it in a timely manner (to supplement, restructure the architecture, etc.): which blocks to make now, which ones can be completed later; what can be done in parallel, what can only be done sequentially, and so on.
Here are the main design stages, without which complex projects cannot exist and be maintained for a long time.

Answer 4

2 hours for design, optionally 2 hours for discussion, and then do it.
Questions and clarifications in any case will appear in the process.
Decomposing is good. The only question is HOW to decompose. This is essentially the general architecture that should be thought out in advance.

Answer 5

Do not go deep into planning and design. It is very important to design the architecture, identify some main modules, consider different cases and possible pitfalls. You can schematically draw the structure of the project from the point of view of the code. And do not delay writing the project itself, you will have to redo and refactor something in any case, you need to roll out mvp as soon as possible. it is better to break it down into possible functionality, and gradually roll it out and see what you missed, and proceed to the next functionality. and there are problems in any code, there is always something to improve