Why False Starts Hurt Your ProjectFiled Under Human Factors, Software Process
Unfounded optimism and a willingness to dive into the unknown is a well documented genetic defect in software developers and managers. Unfortunately, these innate bad habits can lead us to false starting on projects, and consequently losing valuable time and money.
False starts remind me of a story inspired by this quote:
Give me six hours to chop down a tree and I will spend the first four sharpening the axe. – Abe Lincoln
To summarize the fable of the master carpenter and his apprentices, one apprentice false started, while the other took his time to prepare first. Guess which one prevailed?
The three roles that are most responsible for false starts are the developer, the project manager, and the client. However the reasons for each jumping the gun are very different.
Developers that false start all have one commonality – the need to heroically flaunt their intelligence. Intellectual pride runs very deep with developers, and problems that are solved very quickly give a boost in intellectual appearance. It is a classic mistake to have enthusiastic developers dive directly into code only to throw it all away.
How does the developer avoid false starts?
First, avoid heroics and never code without fully understanding your problem. Developing on vague or non-existent requirements is a frivolous exercise in coding at best. If your client or manager doesn’t know what they want, then increase communication until you have a firm idea. It is their job to be decisive on what to build, it is your job to build it.
Second, solve all of your hard problems first. Understand what your technical roadblocks are and remove them. If all of the hard problems are solved first, the probability of your project succeeding will shoot through the roof.
Third, always prototype and throw it away. I have seen too many prototypes become product. Just avoid the maintenance nightmare and toss it.
Managers that are not trained to recognize false starts consistently find themselves in a catch-22 scenario.
A manager that sends in the developers prematurely are initially praised for being efficient. False starting gives the team a head start, but the team will quickly fall behind when the real requirements are discovered.
Contrarily, great managers allocate the time to ‘sharpen the axe’ through acts of whiteboard architecture and prototyping. Unfortunately, great managers take heat from uneducated clients because they do not view these acts as tangible progress.
Developers and managers are directly responsible for false starts. On the other hand, clients can indirectly provoke a false start if they are not managed correctly.
Recently, a client asked for an estimation worksheet and a proposed test plan before they would share the core requirements. Additionally, they wanted to start holding weekly iteration meetings a full month before resources would even be free to start development. Talk about putting the carriage before the horse…
Unfortunately, some managers entertain these silly client requests thus wasting valuable time and budget. It is no wonder most developers have experienced being told they are already over budget on the first day of a project!
No single role can independently prevent false starts. It is the responsibility of the entire team to help each other stay disciplined and focused. Projects are like marathons that need to be prepared for appropriately. When the starting gun is fired don’t sprint, and instead run at a constant predictable pace and you will cross that finish line.