When one admits that nothing is certain one must, I think, also add that some things are more nearly certain than others - Bertrand Russell
It is not certain that everything is uncertain - Blaise Pascal
Do not expect to arrive at certainty in every subject which you pursue. There are a hundred things wherein we mortals ... must be content with probability where our best light and reasoning will reach no further - Issac Watts
God does not play dice with the universe - Albert Einstein
Not only does God play dice, but sometimes he throws tthe dice where we can't even see them - Stephen Hawking
Synergy means behaviour of whole systems unpredicted by the behaviour of their parts - R. Buckminster Fuller, What I Have Learned
Proof, n. Evidence having a shade more of plausibility than an unlikelihood. The testimony of two credible witnesses as opposed to that of only one. - Ambrose Bierce, The Devil's Dictionary
"Contrawise," continued Tweedledee, "If it was so, it might be, and it if were so, it would be; but as it isn't, it ain't. That's logic! - Charles Lutwidge Dodgson (Lewis Carroll).
The notion that estimating is not needed in the software development world is supported by the #NoEstimates paradigm. Except by those who say #NoEstimates does not mean No Estimates. That's a logical loop if I've even seen one.
The notion that #NoEstimates is not really No Estimates (from a recent tweet) fits well with the Lewis Carroll quote.
Here's the deal. If you're writing software using someone else's money, you're going to need to come in contact with the reality of making an estimate of the cost to write that software at some point. Either you do it, or someone will do it for you and hand you a budget for your efforts.
If that's the case, you're going to have to estimate what you can provide them for that money in terms of features or capabilities.
If you work in the development business and never have to estimate your time or cost, you're called labor. In the business world, someone, some where, some how, needs to estimate the final cost of the project.
Here's how to do it using a simple binary search approach. We all remember writing a binary search right? I do, in FORTRAN 77 even.
- Business Owner - I'd like a couple features added to my warehouse management web app, here's a short description of them. How long do you think it will take?
- Programmer - I don't really know how to tell you how long.
- Business Owner - OK, let's try it this way. Can you that done in 100 days?
- Programmer - Oh, sure no problem.
- Business Owner - how about 10 days?
- Programmer - no way!
- Business owner - how about 80 days?
- Programmer - ah, sure I think that's possible
- Business Owner - OK, how about 40 days?
- Programmer - boy that'll be tough
- Business Owner - OK, how about 60 days?
- Programmer - yea that's better than 40 days? It's possible
- Business Owner - OK, how about 50 days as a starting estimate?
- Programmer - Uh, let me think, yea I'll go with that for now, until I get a sense of how much work there really is.
You get it? In 4 questions, you can within 17% as a start, with little information other than clearly outside the bounds starting points. This approach should take about 60 seconds.
So if you are of the persuasion that estimates are somehow evil and should never be done, or it's simply not possible to forecast the future, then this is a moot point. But if you work in a domain where those giving you money to write software and are obligated to have an estimate of how much money that will be from either simple business commitments, or they themselves have to budget for how much they spend on your efforts, you can get to a starting estimate real fast and start developing to confirm your estimate.
