I Refuse to Lie
Imagine a conversation between a developer and an executive in a casino. They're standing next to a roulette wheel, and the executive has a huge stack of chips representing a major portion of the company's assets:
Exec: I need to know what number is going to come up next.
Dev: Uh, I don't know.
Exec: What do you mean you don't know? I pay you to give us estimates. It's part of being a professional to let the business know when things are going to be done. We have to be able to make plans. There are other parts of this business than development that have to schedule their activities. Now what number is going to come up?
Dev: Well, there's an excellent chance that the number that comes up next will be red or black. I see that this is a french style wheel, so the number that comes up is going to be an integer between 0 and 36. There's a small chance the ball might go flying off the table. There's a small chance that the dealer will close the table and there won't be a next roll. There's a small chance that the power will go off and we won't know the result of the roll until the lights come back on. I'm sure there are some other corner cases I haven't thought of. It's really difficult to tell which number is going to come up as the distribution is random.
Exec: The future of the company depends upon being able to accurately predict which number is going to come up! You're just giving me a bunch of useless information about the problem. I understand that you might not be right, but I need your best estimate! If you won't do this, I'll find someone that can! Your job is on the line!
Dev: Ok, 17. 17 is going to come up.
The Exec places all of her chips on 17. The wheel rolls and 27 comes up.
Exec: You are incompetent! You've killed the company! Your estimates are never right! You're FIRED!
So who's the idiot and who's immoral?
The Exec is both an idiot and immoral, and the Dev is immoral. The Exec is an idiot for thinking that bluster and the exercise of power can change the fact that the Dev doesn't know. Management through intimidation is just stupid. The Exec is immoral because they forced the Dev to lie -- and the Exec knew that the Dev would have to lie. The exercise was about shifting the blame for not being able to make predictions about the unknown. The Dev, on the other hand, is immoral. There was a conscious choice to lie. And it was a lie with huge consequences to the company.
The above conversation takes place more often than anyone would care to admit. The fact is that we rarely know the true size of a development project until after the project has been completed. Sure, for very small efforts we can be fairly accurate. But as the size and complexity of an effort increases, the accuracy of predictions decreases dramatically.
If the task is to build a house, we can make fairly good predictions about when the project will be completed. There are variables such as labor unrest, materials shortages, weather, etc, but in general we've built houses before and can get a pretty good idea of what the next one is going to take. Software is different. In software, we're almost always building something that has never been built before. It's a process of innovation. We don't know what the solution is until we've arrived at the solution. We are literally trying to predict the unknown. Can someone please tell me when we're going to have a commercially available warp drive? This is one of the many reasons that software is not an engineering discipline.
The Exec does have a point -- we developers are professionals and we must be able to provide estimates that our partners in the business can rely upon for their activities. We can't just throw up our hands and say you'll get it when it's done. The problem is that at the beginning of a project our estimates are nothing more than SWAGs. A SWAG can be useful as we can let the business know if it's bigger than a breadbox. Sometimes things that appear very simple are really hard and vice versa. I find that because of my experience I can predict a two week effort with about 95% certainty. Four weeks drops down to 80%. A year long project, on the other hand, can be off by an order of magnitude either way if there are big unknowns, such as is this even possible? Making predictions about how long it will take other people to do things is even harder. As we learn more as the project proceeds our estimates will improve. Therefore, the only moral thing to do is to provide estimates of ranges according to what we know. The moral thing to do is to tell the truth as we know it.
BTW, the bird problem from XKCD is a classic, but it's dated. It's been solved!
If the project is a small effort and can be reasonably predicted then we can say things such as there is an 80% chance that this will take us 4-6 weeks to get done. But for a large and complex effort, that range is going to be fairly large as well. That estimate might be that there is an 80% chance that this will take 6-12 months. That's not terribly useful to the business, but it lets them see their worst case and they can plan around the 12 months. A month later when we know more we can refine our estimates. Perhaps then we say there is an 85% chance it will be 8-10 months. Sometimes the answer has to be "I have no idea." Which should be followed up by "We can do a month of investigation and prototyping to try to figure this out and eliminate some of the unknowns and come back to you with a range."
Business people hate surprises, especially unpleasant surprises. Surprises are the result of risk. Pushing the responsibility of estimates onto the developers is an attempt to put the risk on the developers. Developers should not totally accept this risk. The risk is something that should be shared by both of the partners in the relationship. What developers are morally required to do is to decrease the surprise factor as much as possible, and they can do that by being transparent about their level of uncertainty. When you know the estimate has gone from 6-12 to 8-10 you have to communicate that -- you can't sit on the original schedule. Likewise, if it goes from 6-12 to 12-18 you have to let your partners know immediately. It is completely unacceptable to wait until month 12 to then let everyone know the estimate is really 12-18. A developer is morally and professionally obligated to let their partners know when things have changed.
One of the pernicious sins sometimes committed by business people is to set an end date for a project and tell the developers what they must deliver by that date. This usually does not involve a change in resourcing (and if it does it's mostly useless -- the time to change your resource level was 24 months ago, so hop in your time machine and make that happen). These dates are usually associated with some other event. For startups, it's usually along the lines of that's when our funding runs out and we need to have something to show for the next round. And the worst thing that a developer can do is to just go along with that. That estimated delivery date is a lie. Both sides know it. Being wrong can be extremely damaging to the company. Many developers participate in the lie because the worst case is the company folds and they can find another job. Many business people participate in the lie because they think they'll win the coming blamestorm. This is despicable all around.
If the end date and the resource allocation are set in stone -- and sometimes that has to be the case -- then your estimates still have to be in ranges with confidence levels. A partnership between the business people and the developers can help refine what the feature set will be. As the project progresses and the estimates become more accurate that feature set can be adjusted. But you can't guarantee the trifecta of date, features, and resources when there are still giant unknowns. That's nothing more than a bet on a roulette wheel and it hurts everyone. If a developer had the ability to predict the unknown they wouldn't be working at your company -- they'd be too busy winning at roulette.
This reality requires acceptance by both business people and developers. Developers have to be willing to say no and stand their ground. Business people have to accept that both sides must bear the risk of the unknown. Developers must be transparent about what they know and don't know. Business people must manage taking into account the ranges. For my part: