Another heated and high pressure meeting and this time it is to “discuss” how best to “bring back on track” the head line project, the deadline which has already long since past. Sounds all too familiar? I would like to say that late projects can happen in any line of work. While this is true, it appears software development seems all too prone to it.
How did we end up here? We need to backtrack to the start of the dream. It all usually starts full of energy. A new shiny idea and this time we promise ourselves that we will avoid the mistakes we made in the last one. This time we tell ourselves it will be done _“properly”_ and no more shortcuts or hacks. Sometimes this dream for a brief while does seem to go right, the design makes sense, everyone is optimistic and the buzz is good. Then it begins the descent into the nightmare, as the first cracks start to appear.
That easy part of the system now consumes all your time. A slight oversight has meant the initial set of simple assumptions no longer holds. The wrong assumptions has cascaded the design into a dead end. Hacks are now needed to fix it. But there is still hope, with enough weekend coding and late nights we can bring it “back on track”™.
The milestone presentation demo are shown, and everyone is optimistic as the demo has gone well. The others are not aware of the hacks and late nights used to make it all work. Then the “small requests” come in. They usually start with “How hard would it be?”, or “This should be really easy!” and the classic “It would be amazing if we could..”. In conversation these small additions not only sound “easy” but doable. Of course you don’t say no, the downward spiral has already begun.
Now you and your team are back in the real world, looking over the new additions. Suddenly after a closer look it appears the “easy feature” is not quite as simple as it first sounded. But it is too late you have already agreed with management the new changes.
“Ping!” you have a new email in your inbox, great more fuel for this runaway train. Sales have spoken to end customers. Sales spoke about the “easy” additions and the customers wanted a few more “easier” requests of their own. Sales have agreed because it sounded even easier than their own easy requests.
Stop, just stop
During the early 80’s and 90’s a popular advertising campaign of “Just Say No” was used to try and stop or stem drug use by children. Whatever your memory of that campaign the message is a powerful one. In much the same vein we might do well to take heed of this concept.
I am not suggesting that every change are turned down of course. Personally I would draw the line any-time coding development would be required. Things like GUI or front end changes which would be minor should be exempt.
All requests should be given due time to be fully considered before accepting it. Mentally the default to new features should be “just say no”. It is likely this response may not be seen positively, this should be handled with delicate diplomacy. At the start of the project if a process of “Request for Change” (RFC) is not in place it should be considered. Any new late features should also go through this process. With this process it is easier to say “no”. Because a metric can be applied, everyone is clear of the time cost of a late additional feature. The responsibility are then placed upon stakeholders to choose either to extend the deadline or make time by dropping a different feature.
There are a myriad of different reasons why software projects fail to complete on time. The difficulty of estimating development time is only compounded with developers steam rolled by project creep. Knowing ahead of time that additional features may be requested should be at the back of a developers mind. A new mantra of “just say no” would at least stop developers from saying yes by default. Running around with a gun is dangerous enough, perhaps if we put the safety on we might just stop from shooting ourselves in the leg.