You should do enough planning to see the light at the end of the tunnel but not so much that you are almost guaranteed to toss out much of your plans. How can you know when you hit the planning sweet spot? Experience. There is no magic formula.

I have spent well decades in this business. I have run a great many projects, among which were quite a few that I bid successfully and delivered on time.

The essence of a software project plan lies in knowing that you have all of the pieces in place and have estimated them. Some parts will go faster; some will go more slowly. You will encounter unexpected problems. Allow for these events in your plan.

My plans consisted of a brief description of each piece and a time estimate. I always allowed days or a week between completion of my initial plan and review so that I could take a fresh look. Based on long experience, I always doubled my time estimates. Others will have a different rule of thumb. That was mine. Nearly every time, I had the lowest bid, and I always had the completed, documented program done on time whether done by me alone or by a team.

Speaking of documentation, it has the same issues as planning. You can either overdo it or under-do it. Good coding means fewer necessary comments. Each module and method must be clearly documented in any event. So must data structures. Ideally, the documentation will be in clear, correct English.

Too much documentation clutters the code and actually impedes maintenance. Too little is a disaster. Check those who write code for you to make sure that they exercise good judgment in this area.

A note on cowboy coding — A single programmer is more efficient, per person, than a group. This is not a license for crazy coding practices, however. I’ve had all sorts working for me and had to deal with old code from all sorts as well. The only time that you can accept cowboy coding is when you will never modify the software. The costs of revising and updating such programs is prohibitive. Even a solo programmer must be professional.