91–100 of 100 posts
Earlier quoted context omitted.
> you pick the highest-ROI project from the backlog How do you calculate the return on investment without estimating the investment?
You don't have to know the ROI value of each project, just compare their relative sizes to select the best from the set of projects with the highest profit ranking. This assumes, though, that the best of the projects is worth building in the first place.
Earlier quoted context omitted.
That does depend upon your circumstances however. Often there are hard dates that can't be moved - because they are external to your organisation; the autumn TV schedule, or launching at a particular conference are two that have hit me in the past. Of course that does make the estimation a slightly different process - not "when will this be done" but "can you be ready before this date?"
Sure. But instead of estimation, one can take a risk-management approach to that. For example, I'll get people to talk about everything they want. I'll put each thing on an index card. I'll have them lay the index cards out in order of importance (or ROI) on a big table. Then I'll ask: "Draw a line where, if you didn't get that far, you'd just bow out of the conference." Typically, that line is pretty early, 10-30% o…
It's a bit like nature-inspired computation approaches to problem solving. They tend to introduce a lot of overhead that more direct algorithmic solutions won't, but you can terminate them at any point and get something. That flexibility is often very useful.
Earlier quoted context omitted.
That does depend upon your circumstances however. Often there are hard dates that can't be moved - because they are external to your organisation; the autumn TV schedule, or launching at a particular conference are two that have hit me in the past. Of course that does make the estimation a slightly different process - not "when will this be done" but "can you be ready before this date?"
but "can you be ready before this date? IMHO right answer to this is, Yes we can be ready but we might have to scale down on some of the features. But in reality most of the time only the initial 'Yes' part is heard with the caveats being ignored. As mentioned many a times it is "quality, features, schedule" and one can pick only two.
Earlier quoted context omitted.
I believe that's his point.
Then the larger point is that if estimates are always imperfect, we need to stop obsessing about their always being imperfect.
Earlier quoted context omitted.
Your last remark is true, but a bit falsely dichotomous. The choice isn't between perfect estimates and zero wastage. In practice all projects lie on a continuum between totally novel and pointless duplication. Within that continuum we can draft estimates of varying accuracy and I don't see a reason why we shouldn't.
The amount of time we get is fixed. Estimation is, from the Lean persepective, muda (normally translated as waste). If I can be spending that time instead on an activity that reduces the waste of duplication, I'd rather do that. I should be clear that I'm not totally opposed to doing estimates. I've done a lot of them, I'm good at it, and there are circumstances where I would do it again. Some waste is temporarily ne…
Estimates can prevent waste by giving us a better of idea where to redirect effort. Time is, as you say, doled out at a constant rate.
The highest ROI possible for an estimate is to prevent wasteful effort from proceeding.
Timeboxed systems still perform estimation, you just hold different variables constant. In flow-based systems you can perform estimates by taking an integral of the current output.
My point is that estimation is always present, even when we go out of our way to say that it isn't. They lie on a continuum from gut feel to supercomputers and conference papers. Estimates are always present because humans must always reason under conditions of uncertainty; the future is strictly unknowable.
Part of the confusion here is that I think there are two or three definitions of estimate in this thread. I am talking both about the universal case and the methodical estimate-with-an-E case. The universal case is that all decisions leading to action or inaction involve estimation. The methodical case is that estimation for software development is possible and tractable outside of genuine research.
Earlier quoted context omitted.
> Regardless, I think drawing physical analogies for software is risky; software is infinitely soft. Sure, but I also think that this doesn't imply infinite intractability for actual problems. That a problem is NP-hard, for example, doesn't mean we can't find quite-good solutions to it that have business value. > And either you don't know what they do or you're drawing a false analogy between traditional planning pro…
I did not say that the Internet was not designed. But I'm glad to say that now. Specifically, it was not designed in the sense that megaprojects requiring planning and estimation are designed. My point there is that people just assume that big achievements require big plans, but that is demonstrably false. I do agree, as a long-time reader of RFCs, that some of the protocols were designed, sort of. But if you read mo…
Right. Some systems can't be designed that way. But that doesn't mean that no system can be designed. And it doesn't mean that all systems are better off being designed or not-designed.
The reason megaprojects tend to be planned, controlled etc is because they haven't spontaneously emerged on their own. Somebody somewhere wishes to make a positive effort over and above the current baseline.
> I agree that some projects can be estimated. I'm saying a lot of them shouldn't be, because there are more effective ways to get results.
Agreed. A lot of the time a formal estimate isn't necessary. But a "lot of the time" is not the same as "always".
> An instructional contrast is the OSI protocol suite, a top-down alternative to the Internet. Now dead, of course.
There was a good history article on OSI in a recent IEEE or ACM magazine. The two major problems were an irreconcilable fight between circuit-oriented and packet-oriented designers (so they did both) and then lashings and lashings of vendor politics. The author of the piece argued that TCP/IP worked because it was driven by a small group of designers who just went ahead and cut code.
Generally the IETF model has worked because it's done by small groups focusing on a narrow problem in an environment of independent, interacting agents. Some systems work really well that way. Some don't.
> You can read more about that, and about the 3M example, in Mary Poppendieck's books. I think the specific one I have in mind Leading Lean Software Development.
I'll pick it up, thanks for the reference.
Earlier quoted context omitted.
Suppose you're asked to estimate a single sudoku problem. That's basically impossible, because n=1. In small samples from a large population, variation is enormous. But what if I ask you to estimate the time for 100 sudoku problems? For 1000? What if, after 2 years of solving sudoku problems full time I ask you for your estimate? What if I develop simple statistical models based on the number of squares that are alre…
"What if I develop simple statistical models based on the number of squares that are already filled in?" Better to just have the experience to look at a Sudoku and have a good feeling for how difficult it is - it's not just the number of filled in squares but their locations and their values. After solving 1000's of Sudoku problems, experience will allow one to see the relevant patterns or rather have a feel for them…
Could you elaborate? What would one estimate on a book of sudoku problems?
I ALWAYS quote fixed price projects regardless of scope. Some software engineers would say that's highly risky. For me, it tends to be highly profitable because my estimates are usually accurate. If anything, I've learnt to over estimate and impress clients by delivering on promises. I am amazed by the number of people who try to portray computer science as a pseudo science like voodoo, where estimates are impossible…
edit: also, could you email me please? I'd be interested in asking some questions.
Earlier quoted context omitted.
"What if I develop simple statistical models based on the number of squares that are already filled in?" Better to just have the experience to look at a Sudoku and have a good feeling for how difficult it is - it's not just the number of filled in squares but their locations and their values. After solving 1000's of Sudoku problems, experience will allow one to see the relevant patterns or rather have a feel for them…
> A longer way to developing meaningful estimates (and I prefer meaningful over accurate, since a good estimate can still be very wrong), is to avoid estimating one's time as an end in itself. Could you elaborate? What would one estimate on a book of sudoku problems?
An estimate of how long it will take me to solve 1000 Sudoku for recreation will not have much meaning to a client who just wants the solution.
What are the resources that will be brought to the task?
An estimate for solving 1000 Sudoku with a staff of professional programmers will be different from one premised upon bribing a dining hall full of seniors with coffee, juice and donuts down at the retirement village.
What is the unit of estimation?
Calendar days until delivery is different from man-hours because I spend so much time on HN.
The value of an estimate is the integrity and relevance of the process by which it was generated not its accuracy. Accuracy is a fortunate side effect - and then only sometimes. The key is that accuracy correlates to experience at making estimates, and rationalizing the failure to go through the process because past estimates have been inaccurate is the long road I mentioned.
Earlier quoted context omitted.
Interestingly, Thoughtworks have observed that over a project they get the same consistency simply counting number of tasks as counting effort estimates for those tasks. The key for project management is therefore to focus on maintaining a backlog of manageable tasks and throughput, not in estimating them individually.
That's an interesting finding. Do you have a link to the research?