A Different Approach to Deadlines in Development
I think every developer hates the word deadline.
Why is this?
Probably because deadlines in development the word usually means stress and pressure.
But is it supposed to be this way?
What is the purpose of a deadline?
Do they need to be stressful and feared?
Let us take a look at what the definition of a deadline is according to Wikipedia:
“the latest time or date by which something should be completed.”
In other words, a deadline is a goal or vision.
How do you make a goal easier to achieve?
One way is by breaking a goal down into steps.
These steps become a journey towards achieving the goal.
Using the approach also makes it easier to track progress and assess whether the goal will be achieved by a certain date or not.
The same process can be used for development.
By using a journey approach for development, you can progressively achieve your deadline.
Why is this useful?
Any problems or issues can be dealt with earlier which has an important impact on your deadline.
It also makes a deadline more achievable.
I’m not saying using the approach will guarantee that you meet your deadlines every time, but you will know a lot sooner if the deadline needs to delayed which then helps manage expectations.
Chances of delaying a deadline in development seem to be extremely high due to unforeseen things.
In my experience things never seem to go as planned which results in changes needing to be made.
Depending on what needs to be changed, it can greatly affect whether the deadline is achieved or not which is why deadlines should be adaptable to some degree.
A deadline should also allow for extra time in case it is needed, as the saying goes “under promise and over deliver” rather than “over promise and under deliver”.
How can this be applied in a development environment?
A deadline should be the goal of what the project wants to achieve by a certain date.
To use an example, we want an app that can do X, Y, and Z by date.
Using the above, we know what we want to create by when, now it is time to break this down into the steps needed to achieve this by starting with X, Y, and Z.
Does X need to be broken down further into Xa, Xb, etc?
If it does, then first break it down along with dates.
I don’t believe these need to broken down further otherwise it could result in things getting to granular.
When I break things down, I try to ensure that each item has a certain purpose.
What do I mean?
Using the example above, let’s say X was a user account.
I would break that down into:
- Xa: Render user account details
- Xb: Update user account details
On the other hand, if X was parse CSV to JSON, I wouldn’t break it down further as it is already definite.
Once you have done this exercise you will know what steps need to be taken to achieve your deadline.
What if the dates in the break downs don’t match the deadline that was given?
If this happens, you have two options either extend the deadline date which is the option I would choose, or adjust dates in the breakdown.
Even though the latter is an option, it can result in introducing problems this approach tries to avoid.
I believe this approach is more effective than saying we need X done by Y.
I hope you have enjoyed this post and found it useful. If you have any comments or suggestions please let me know below.