The book Understanding Software describes starting the right way.
How do you keep the design simple as the codebase grows? We want to avoid having a large codebase with no sound design. This could lead to the Big Rewrite, where nobody wins.
While incremental efforts such as refactoring could alleviate the pain of not having an established design, the team effort could have been prevented had there been some type of guidance at the beginning of a software project.
But what if you don’t know what the “right way” looks like at the beginning? A design would eventually emerge given enough time working on the system. This insight will not appear when you are pressed for time to build something or if your tenure in the project is measured in weeks.
To counter paralysis in choosing the “right design,” sometimes you just have to build something and stay long enough to experience the pain points of your implementation. Only by experiencing pain can one be instructed on how to improve their designs, especially after being paged at odd hours of the day.