When you work in a development team, especially one of a reasonable size, you eventually end up spending a significant amount of time on planning and preparation.
This is necessary to ensure that the output of the team moves in the right general direction and nobody would suggest that chaos is more desirable alternative.
However there is such a thing as analysis paralysis and sometimes there are advantages to having an attitude of "just do it".
Learn By Doing
Software development is a cerebral activity that requires upfront thought, simply starting to bash out code will very likely result in a slightly incoherent code base with a lack of discernible architecture.
On the flip side any problem of significant complexity will prove difficult to get to grips with purely on the white board. No matter how carefully you try and map out a solution you will always discover problems in your thinking once coding starts.
This is a difficult balance to strike and relies on having a sense of when more thinking is required and when more diagrams won't help and the time has come to try something out.
This has to be coupled with an Agile mindset of expecting bumps along the road and being prepared to adapt and think on your feet when a wrinkle in your thinking is revealed.
Software Over Documentation
A consequence of trying to move to the coding stage quicker will be that you will naturally accumulate software faster than documentation.
I do believe documentation is important and your thinking behind a system should be available for others to consume, it is simply a matter of detail.
The details of exactly how something works change and the code that implements that detail will always be the best documentation of it, ultimately its the single source of truth as its actually doing the work.
Documentation should provide enough insight to indicate intent to those that read it to guide future enhancements in the right direction.
It shouldn't delve down into the inner workings of the machine and it certainly shouldn't do that before the building of the machine is underway.
Embrace Failure
The underlying narrative of this thinking is one that people sometimes find difficult to contemplate.
Not everything is going to work the first time you try it. Software development is way to complicated an activity for that to ever be the case.
If you accept that fact of inevitable failure then the choice is a stark one, would you rather fail after months on the drawing board or would you rather fail after a shorter amount of time with at least the possibility that some valuable software has been created even if some is also flawed.
There is also an implication that failure has to be managed, both with its impact on timescales and delivery, and also defining what is an acceptable level of failure in a design if we still want to ship it.
This last part is in essence the nature of an MVP, its acceptable for a design to be flawed in that it doesn't support all possible features or functionality. What isn't acceptable is that its flaws prevent those features from ever being implemented in the future.
The role of any software development team is to produce software that addresses a business need.
That doesn't mean software should be produced at any cost, a lack of thought in what your doing will always catch you out in the end.
But no design will be perfect and no solution foolproof until they have been proven with working code that implements them.
The sooner you can move on to coding the quicker you will gain a warm feeling that this will work, or sooner you will receive the feedback that a new approach is required.
If you arrive at the stage that you think I need to try this out, just do it.
