The Software Uncertainty Principle
My Dad, a software developer in his younger years, liked to tell me his version of the Heisenberg Uncertainty Principle, except his applied to software development:
If you know what's in it, you don't know when it'll ship. If you know when it'll ship, you don't know what's in it.
As a programmer myself, I haven't found many exceptions to this rule. Whether you ship once a day or once a year, there is too much uncertainty in building software to make good predictions about when things will be done.
Yet most existing software processes ignore this rule and resort to constraining feature sets and delivery dates (ex. sprints) — which creates dysfunction.
What if we took this rule seriously and built a process around it? Instead of wishing it wasn't true? What would that process look like? Looking at the four general categories for release strategies, we can get a rough of idea of what some of the alternatives might be.
1. *Forbidden* (Fixed Scope, Fixed Release Date)
If you take the software uncertainty principle as a given, then this category is forbidden. Any attempt to pick a set of software features and a date for which to release them is disqualified (ex. sprints/iterations, waterfall planning). In fact, for this intellectual exercise, the whole concept of a deadline is probably off-limits. What else is a deadline if not a fixed scope and fixed release date. So, if deadlines are off the table, whether they are large (waterfall) or small (scrum), what is left? Let’s look at categories 2-4.
2. Check-in (Variable Scope, Fixed Release Date)
If you leave your scope undefined, but fix a release date, you are essentially establishing a reporting schedule, a time to see how far along a programmer is — a time to demonstrate progress, discuss changes in direction, and give feedback.
While there wouldn’t be any specific expectation about what should be complete — that would be a deadline — you could use a check-in to make a subjective assessments of effort and progress. Sometimes, your only progress will be to simply identify that something didn’t work. Other times, monumental progress may have been achieved. A good manager will be able to evaluate and help in either situation.
3. It’s done when it’s done (Fixed Scope, Variable Release Date)
Sometimes you know what you want and you don’t really have anything until you get there. In that case, the only choice is to crank on it until it is done. This is the category that causes the most tension between managers and programmers (second only to category 1 of course), especially if tasks take much longer than expected. A good manager will set up category 2 check-ins along the way to alleviate that tension, and provide necessary input and assistance.
4. R&D (Variable Scope, Variable Release Date)
This is discovery work. Not only are you unsure of what you are going to end up with, you aren’t sure how long it will take to get there. Most companies are afraid of spending too much time in this mode and unfortunately bias toward things that are more concrete. This is unfortunate, because the best solution is often hiding in the uncertainty of the problem domain and can only be discovered by playing around a bit.
In category 4, all you know is that when a programmer has something interesting, they will share it. No one knows when it is coming or what it will be. But I still think this type of work is worth the effort. If you stumble onto the right solution, it could change everything for the business.
Conclusion
There are certainly a lot of options to explore in these three categories. But it’s a worthwhile effort. Because they don’t fight against the uncertainty principle of software, categories 2-4 have the potential to eliminate the troubles associated with category 1 thinking (ex. death marches, stress, unrealistic expectations) that have dogged our industry from the beginning.