There is a sad story I will tell you now, a story which – I guess – most developers have been through at some point in their career.
We are in the middle of developing a project. There was a time, some months ago, when the deadline looked so far away that we coded happily and without pressure. We did not care about new requests, because we still had a lot of time. But now the deadline is approaching. Suddenly we feel we may not actually complete the project in time! We increase pace, we cut some corners, we live a stressful few weeks, and finally we deliver in time. Yay! Now we only need the people from the customer to do their tests and confirm everything is ok, but basically the project is done.
Alas, it is not.
First, we have to wait for a while, because the customer suddenly has something more important to do first. When the test is actually performed, a lot of things are reported as “wrong”, i.e. they were expecting something different. We realize that during the final race to complete the project we did not speak enough with them. And of course, we have to fix some bugs because when you code in a hurry, well, bugs happen.
The original deadline is soon forgotten. The project moves on, with bad mood from all sides, until somehow it manages to take life or crumbles under the unaffordable effort required.
Sounds familiar? I assure you this happen quite often in software industry, even in some of the best-known companies. There may be many causes for what can be considered a “less than perfect” outcome, but we will focus on a big evil: a remote, arbitrary deadline.
In software development, a fixed deadline months away from now is a fairy tale. This is because of many factors:
* developers are usually not very good at estimates
* coding requires often to solve business problems never encountered before and, as such, not easy to estimate anyway
* business people have every right to change their mind along the way based on new data and new ideas
So you simply should not set a single remote deadline, because all bets are that it will be wrong.
Of course I do not propose to completely ignore deadlines, but I propose to change the scale. Instead of trying to guess the date when the whole project will be done, try to guess what you can complete in the next 1 or 2 weeks. Suddenly, it all becomes much easier. You are perfectly aware of the current situation of the project, you may decide what to do next based on frequent feedback from customer, the project can (and will) be tested at any time, and the quality does not suffer.
In most cases, completing a project a few weeks later is not a big problem for the business. But getting a low quality project, THAT is a problem.
By following these simple rules, you’ll have a better story to tell next time.