Why False Starts Hurt Your Project
Filed Under Human Factors, Software ProcessUnfounded 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.
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.
4 Responses to “Why False Starts Hurt Your Project”
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.
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.
A good article, but my critique of this analysis is that the difference between “a false start” and “working toward an early prototype” is often only clear with the benefit of hindsight.
One always has to be careful not to end up trapped in the metaphor. Software development is not wood chopping, nor is it carpentry, nor is it a marathon.
But there’s no argument on the need for design – it’s enormously frustrating to realise that a client doesn’t know what they want, and downright irritating if they won’t accept that this is a problem.