Science doesn't work with deadlines
Balancing solutions that don't live long with discovery
Deadlines are problematic. There are as many ways to argue against them, as there are ways to argue for them. In software development many methodologies for project management have been created in order to help deliver products on-time. And yet, putting a deadline on a project will invariably make the process complicated and stressful.
A co-worker of mine gave me a great way to frame the idea of deadlines in software development. I was saying to them:
In all the time I’ve been doing software, I’ve never figured out a way to explain how deadlines are utterly useless and in many cases detrimental to the momentum of development.
Their response was amazing because it made me realize I was only considering half of the problem, and that there is a deeper issue. They said:
There is the “engineering” part of software development where you are simply composing solutions together in order to build products, but all the other work is truly “computer science” and in that part there is no deadline if you’re doing it right.
Scientific Method vs. Solved
In fact we can (and should) apply timelines to work when we have known patterns and practices that are predictable and highly repeatable. However, for things we’ve never done before there needs to be a scientific method applied to build the highest quality products. Once we find the best solution, then we can very often re-use it as a pattern to improve the time it takes to build the same thing in the future. This makes deadlines approachable.
But there is a trap. The trap is solutions and patterns we make don’t live long and we oscillate back and forth between discovery and composing solved things together. We go from “widget stamping” to “blank page syndrome” in unpredictable ways. Applying a timeline to that will destroy discovery and potentially force a pattern to live beyond its advantage.
The key element we neglect is that a large part of software development is good old-fashioned scientific method. In order to get to the widgets and patterns you have to spend time discovering what they are and how to use them best. If you’re applying a proper scientific method to this (and usually you are) then any given result from a test could cause a redirection of the solution, and inevitably add more time. And herein lies the problem.
Expectations
Delivering software on-time is extremely difficult. As soon as you have a date, you now have pressure. And given we operate with healthy use of existing solutions, and balanced scientific method, we must now deal with managing expectations.
Most often the root of the issue is in what exactly we communicate to stakeholders along the way to the deadline. We often don’t include the work that we already have solutions for, but instead we only communicate what we are “stuck” or having unexpected outcomes with. And that creates a misperception of lack of progress. This is rarely true. On a daily basis there is always progress. Even if that means we learned how not to do something.
Communication
If we improved how we let stakeholders know about these parts of the process, it’s very likely the expectations would improve. And why not tell the stakeholders exactly what you’ve learned? Isn’t this a positive outcome regardless of missing a deadline? In my experience it’s always a good thing to hear:
We discovered that our implementation was really slow and we now have to change our underlying data model in order to improve the scaling ability of the solution.
The trouble is usually in how we explain these setbacks. We neglect to outline all the ways that we are learning how the solution shouldn’t work, and filtering down to the way that it will work. That’s progress. It certainly means a deadline might slip, but at least we can improve expectations and perceptions by describing the truth of the matter.
There are many ways to improve these communications, however there isn’t a set of templates to use. Each product is different, teams are different, and stakeholders are different. What is required is the ability to be clear and adaptive in your communication to assure that the right expectation is being set and that false perceptions are avoided.
Deadlines are a given in the software development process. You will never experience work that doesn’t include some form of timeline and milestones to meet. But they don’t have to be a panic inducing part of the work. We can improve they way we let stakeholders see progress, and even quite possibly make deadlines unimportant along the way.