51–60 of 221 posts
Then he'd say, "okay, what would it take to do what you just said in T/2?" Then you'd cut stuff until you got to T/2. The project then, very often, would take me the original T.
This seemed to work a lot better than just doubling the initial estimate to 2T.
> Sometimes it takes a conversation with someone else unfamiliar with your work to really question your fundamental principles This is one of my favorite tools for development. I always sketch out an idea (no coding) and then try to describe it to someone with zero CS background before diving into an mvp. The times when I didn't follow this process - well - just as op described while trying to document the cli, I bas…
I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.
I once had a manager who insisted on time estimates, but used them in a way that I actually found valuable. You'd write out all the tasks involved in a project add them all up, and then say "this will take T" Then he'd say, "okay, what would it take to do what you just said in T/2?" Then you'd cut stuff until you got to T/2. The project then, very often, would take me the original T. This seemed to work a lot better…
I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.
I'm not off by more than 20%.
I can’t accurately estimate non-trivial software. I’ve never met anybody who can accurately estimate non-trivial software. I’ve never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.
I can. Do your estimation normally. If you've done it a dozen times multiply by sqrt(pi), if you've done it a couple of times multiply by pi, if you've never done it before multiply by pi^2. I'm not off by more than 20%.
Consider that many software projects led by experienced software engineers go so far over time that they are never finished.
I once had a manager who insisted on time estimates, but used them in a way that I actually found valuable. You'd write out all the tasks involved in a project add them all up, and then say "this will take T" Then he'd say, "okay, what would it take to do what you just said in T/2?" Then you'd cut stuff until you got to T/2. The project then, very often, would take me the original T. This seemed to work a lot better…
Earlier quoted context omitted.
The non-trivial part might be combining the trivial parts. :)
This is a good point and something probably not caught in the estimation of the smaller trivial parts.
I don't have a statistic, but I'd be willing to bet the majority of code in existence is not algorithmic in nature.
Earlier quoted context omitted.
I can. Do your estimation normally. If you've done it a dozen times multiply by sqrt(pi), if you've done it a couple of times multiply by pi, if you've never done it before multiply by pi^2. I'm not off by more than 20%.
Your heuristic that someone who has done a dozen previous software estimates will not take more than 177% of their current estimate to finish a “non-trivial software” project seems wildly optimistic to me. Consider that many software projects led by experienced software engineers go so far over time that they are never finished.
Category 1 is
>I've written a script to get the data from tables 1 to 24 of this database, now I need to write one for table 25. It should take me an hour.
>Oh look, it took me nearly 2 hours because I forgot that table is owned by a different user to all the other ones and I didn't have the right permissions.