You’ve surely heard the variations on this theme. “Ready, fire aim” was popular in the 1990’s, accredited to any of several authors. I used the term to describe my efforts in the artificial intelligence field, experimenting with new devices, the lisp programming language, and our first trial installations. It seemed an ideal way to describe a scrappy, entrepreneurial activity.
So why do so many business-book authors stress the opposite behavior? Ready, FIRE, aim. What happens to careful planning, sure-fire metrics, quality test scenarios, market research, a good business plan – all in place before pulling the trigger of a new opportunity.
And who is right here?
[Email readers, continue here…] If you’re seeking investment from anyone other than friends and family, you’re probably going to have to navigate through the exercise of careful planning, documentation and execution. Investors are a fickle bunch in general. They want to know that 
their money is not just being thrown at an idea that will become a trial by fire – literally.
On the other side of the argument is the truth of the claim that numerous iterations in the form of rapid prototypes and execution of new ideas in the field quickly refine the product or service to meet the needs of the customer, and at a far faster and cheaper pace than with careful pre-planning.
In the software arena, there is a term for this: “cowboy coding.” Without the need to carefully document the architecture and elements of a proposed application, a single programmer can much more quickly just code, test, and create revised code. Without even pausing to document the process internally, no-one can easily take over the job, if for any reason the cowboy coder is no longer in control. And the result? Typically, we call that “spaghetti code” to signify code that is so often changed that it no longer looks clean and traceable.
The conclusion is that the best process depends upon the product, its critical core nature to the business using it, and the way in which the entrepreneur approaches the need for outside investors.
Critical components of any operation or business must be carefully constructed, tested and inserted into the operation of the business. On the other hand, if a new free iPad app has bugs, they can be corrected in the next automatic update, and probably without much customer noise.
Which is better for you: rapid iteration or careful planning? What is your case for defending your method of creating new products or services?
This is not a black-and-white dichotomy. Zero planning will quickly get you into deep crap. Too much planning will waste time and resources while the market may pass you by.
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.
I go with the philosophy “how little planning can I get away with”. The exercise of planning is a cost. While some cost is absolutely necessary to prevent future losses, extensive planning is not recoverable. Then there is the famous quote “no plan survives contact with the enemy” by Moltke the Elder. So be prepared to change your aim after you fire – even if you took careful aim before.