Why False Starts Hurt Your Project

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

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.

The Developer

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.

The Manager

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.

The Client

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.

This is a very good analysis of the different influences on false starts. One thing I like to remind developers is never assume you have to start coding just because your manager (or your client) thinks you should. Better to sit down and start sketching out the system design before touching the keyboard. BTW, I love the graphics you chose for each role.

Jason, I am going to slightly clarify your developer reminder as if read wrong might be a loaded and dangerous message.

I would tell developers to use your gut instincts when overriding a manager’s decision. Some of their decisions are completely absurd, but if you override them all you will appear insubordinate. Pick your battles and you will win the war.

Justin B on
July 30th, 2007 7:03 pm

Max,

Good article. I had a discussion with Gibb about this topic recently. I think that what you are saying is especially true when less-experienced developers are involved.