On August 5, 2012, the NASA rover Curiosity completed its six-month journey from Earth to Mars, touching down near the middle of its roughly 40-square-mile targeted landing area. Many news outlets compared the landing to making a hole-in-one at a Scotland golf course after teeing off in Los Angeles. Many people and project managers expect the same sort of precision for our product releases: one to three years in advance of the release plan all the work you’ll be able to accomplish. After all, if NASA can be that precise, why can’t we?
Unfortunately, there’s a problem—NASA isn’t that precise. Curiosity had seven course corrections planned for its flight, plus a bunch of orientation adjustments. It didn’t use them all, but NASA engineers constantly monitored the flight and altered course as needed to hit their ultimate goal.
If NASA really isn’t that precise, even with extremely clear starting and ending points, and well-defined, stable requirements, how on Earth (or Mars) are software engineers supposed to be that precise in their planning one to three years out on a project with unclear goals and poorly-defined, unstable requirements? Easy, just do what NASA does: start with a goal and then iterate.
Dumb and dumber
It’s amazing how misguided people and project managers can be. They’ll expect you to hold to annual commitments on projects that change every few months. They’ll hold you to calendar-day estimates on features that have loose, one-page specs and undefined dependencies. They’ll insist on detailed design docs for components that will be totally different by the time you actually code them.
Why are these people and project managers so misguided? Because they are rank amateurs—people confusing precision with accuracy. Just because you are providing consistent, fine-grained detail (precision) doesn’t mean you are actually on target (accuracy). Professionals know the difference. Precision from a great distance is fallacy. The way you accurately hit your target is by first knowing what your target is and then constantly monitoring and adjusting your trajectory. That’s how the pros do it.
Does this mean you don’t write commitments, estimates, or design docs? No. It’s really important to understand your goals, ensure they are feasible, and think through the issues ahead. However, long-term commitments, estimates, and designs are never precise. They are rough, high-level views, and should be written accordingly.
Eric Aside
Precision is like the number of digits in a calculation, while accuracy is how close your calculation is to the correct answer. For example, 22/7 is a common estimate for pi (the ratio of a circle’s circumference to its diameter). Even though you can calculate 22/7 quite precisely (10 to 20 digits on your average calculator), the extra precision doesn’t make the computation more accurate. Only the first three digits of 22/7 are very accurate (3.14). Using more digits leads to fallacy.
Where do you want to go today?
You can’t arrive at a destination without knowing where you’re going. For personal development, that means high-level goals—what Microsoft now calls annual commitments. For software development, that means a high-level schedule, value proposition (vision, scenarios, and tenets), and architecture.
I talk about writing useful high-level commitments in I’m deeply committed. I talk about writing useful value proposition and architecture documents in Coordinated agility and Blessed isolation—Better design. I talk about making solid estimates in I would estimate.
Remember, plans are nothing; planning is everything. Without planning, you don’t know where you’re headed and what might greet you. However, just like Curiosity, you constantly need to monitor where you are and make corrections along the way.
Stay on target
Once you have your objectives, you want to nail them. Remember, NASA was extremely precise in the end. As objectives get closer, you have far more information about them, can make appropriate adjustments, and can vastly increase your precision.
In software development, your high-level plan starts with very rough estimates and an educated guess at the architecture. As work on each feature continues, you know more about the feature’s requirements, get a better understanding of its dependencies, and can nail down its design, implementation, and estimates. It’s just like looking through binoculars: as you get closer, finer and finer details come into view.
There’s no point in starting with detailed specs, implementation designs, and to-the-day estimates. Not only will those items be fallacies, but your inherent commitment to the bad information will only draw you off course. Instead, keep your early plans at a very high level. Then reassess where things are when you start work on each new feature, make adjustments to meet the current better-informed reality, and draw yourself ever closer to your goals.
Of course, requirements and goals often change on software projects. By keeping your early planning at a high level, and constantly monitoring and correcting your course, you can easily adjust your estimates, design, and implementation to a new target with new requirements. Yeah, some time and effort is wasted by pursuing the prior path, but until we find a perfect oracle, it’s best to stay flexible and iterate.
Eric Aside
Since no one is clairvoyant, the real game in product development is failing quickly when you head down the wrong path, thus wasting the fewest resources and time on dead ends. Iteration, especially in changing circumstances, is a particularly wonderful form of failing swiftly and adjusting.
A popular metaphor for how requirements and goals become clearer the further you advance in your project is the cone of uncertainty. The cone is broad at the start, where there is high uncertainty, and then gradually narrows as more and more of the unknowns become defined.
Give the people what they want
How do you deal with people and project managers who demand false precision? Give the fools what they want.
- Convert your rough, high-level estimates into specific calendar days. For example, “t-shirt” costing might convert as follows: small = a few days, medium = a couple of weeks, large = 5 – 6 weeks, and extra-large = 3 – 4 months.
- Detail commitments and accountabilities that stay true to your high-level goals, based on your current best guesses at what matters.
- Document your high-level architecture in a way that suggests high confidence, including educated guesses at a number of design details that remain consistent with the architecture.
However, don’t expend much effort getting the details right—you can’t. Spending months on working out fine details before implementation will provide far more precision, but will be barely more accurate than your thoughtful high-level estimates and architecture. You are far better served spending that time making real progress and discovering the real details along the way. Who knows? Sometimes your first guesses are the most accurate.
If and when your dates turn out to be a bit off, when your commitments change, and when your details diverge, you can say what everyone says—stuff happened. Like it always does. Like it always will. The only difference is that you didn’t put a ton of wasted effort into pretending that you’re a psychic.
Eric Aside
This approach may sound passive aggressive, but it isn’t. You really are making the best possible detailed estimates, commitments, and design decisions you can using the knowledge available. You just aren’t wasting extra time guessing wrong. No amount of extra time will make you right—short of actually building the real product.
The approach is admittedly a bit defeatist. Ideally, your people and project managers would understand that extra precision buys them nothing so far in advance, but people can be difficult to convince. It’s a question of how best to spend your time. You can spend it attempting to convince the misguided, or providing added precision that produces little added accuracy, or building a great product for our customers. I always put customers first. Correcting the misconceptions of others is only a hobby.
The eagle has landed
No one can accurately predict the future. More importantly, no one needs to do so. You can hit a 40-square-mile target on Mars, and a 24-hour release window on Earth, without knowing all the details up front.
However, you do need to know where you are going (a high-level value proposition), the roadmap for getting there safely (a high-level architecture), and your checkpoints along the way (a high-level schedule). Once you’ve started on your journey, you can monitor your progress and make adjustments to your plan to keep you on target.
It’s really not rocket science. You don’t need to be a psychic. You just need to be a professional engineer willing to be honest about where you are, what you’ve learned, and how best to achieve your goals, and then adapt accordingly. You may not know precisely how you’ll achieve your objectives from the start, but with the right level of focus, flexibility, and fortitude, you’ll land your project spot on.
But if I don't work out all the little details in advance I can't be sure that what seemed like a little detail wasn't actually hiding a big problem. And if there was a big problem that I didn't spot then I'm a failure.
There's a few of ways to mitigate that. 1) Have others review your plans. Other people may catch things up front that you missed. 2) Prototype the parts you are least certain about. 3) Schedule the riskiest items first. That way you have the most time (and most alternatives) to deal with them.
Yes, you can do all these and still be surprised, but it greatly decreases the chances.
@c: and how do you "work out all the little details in advance" without actually not doing the work involved? Experience show that it is more the rule than the exception that while you do the work you find new "little details" that you would have not found without doing the work.