By Sheila Eckert
The Merriam-Webster definition of Arbitrary: ‘based on or determined by individual preference or convenience rather than by necessity or the intrinsic nature of something’.
This is not about ‘True Deadlines’ like adhering to a new FDA regulation, implementing code for new tax laws, needing software completed before the start of the school year. Managing true deadlines is a story for another day.
While True Deadlines do exist, often deadlines are an arbitrary date.
While it is good to have goals, target dates and milestones, an arbitrary deadline created to pressure teams to complete work by a given time is fraught with many unnecessary risks and undue stress.
To illustrate, we will look at two scenarios, a developer who has been told that she must complete a task by a specific date and a motorist who is trying to get to his friends house by a set time.
COMPLETE THIS PROJECT BY NOVEMBER 30TH.
ARRIVE AT FRIEND’S HOUSE BY 2PM.
So, both our subjects have tasks with deadlines assigned.
All goes well at first. Moving along on the road. Coding is going great.
Our motorist is stuck in bad traffic.
Our developer has come across a piece of the requirement which is more difficult than anticipated.
Both worry about the looming deadline and determine that if they don’t do something, they will not meet their goal. THE DEADLINE HAS BECOME THE GOAL. And this is where the RISKS begin.
RISK AHEAD
The two are looking to shortcuts so the ‘deadline goal’ can possibly be met. They have lost sight of their actual goal.
Our motorist decides to try a ‘shortcut’ around the traffic but the road he needs is closed. He is now mindlessly following his GPS, hoping it is going to make up the lost time.
The developer starts to look at shortcuts, at cutting corners. She will try to create a less than ideal solution. It should work but we need to forego good coding practices. She is unsure if this solution will scale but there is no time to worry about that now. She introduces technical debt. She limits the amount of testing.
The goal has now gone from result oriented to deadline oriented. Based on how far behind we are, there is a need to speed up further.
Our motorist begins to speed and use dangerous rather than safe driving practices. More risk. Speeding ticket? Car Accident?
Time to code fast, not smart. More risk. Less than ideal solutions. Details missed. Technical Debt. Bugs.
In the end neither of them finishes on time. Risks were introduced and results less than ideal.
Fines to be paid. Repairs to be done. Insurance cost increased.
Bugs to be fixed. Code that needs rework. Features eliminated. High Latency.
STRESS
Throughout the process both experienced unnecessary stress. They did not meet the deadline. The result is not what was expected and much less than perfect.
The GOAL is to ACHIEVE the DESIRED RESULT as quickly as possible.
Arbitrary deadlines do much more harm than good. Use meaningful but looser targets — dates and milestones. Do frequent assessment and necessary adjustments. Code smart, not fast. Limit technical debt. Build in quality.
Following this approach results in quicker delivery of the desired outcome.
