3 ms·

Wow, some of the comments about the costs there are flat out insulting. A well done app is going to take time and money to create and polish, and a simple app i

by Skroob 16y ago

Wow, some of the comments about the costs there are flat out insulting. A well done app is going to take time and money to create and polish, and a simple app is almost always anything but simple. Twitteriffic is a well done, "simple", polished app, and $250k seems like a good number to me. Personally, I'm still learning how to bill my time out properly. I've got a serious case of underestimatitis. Maybe Craig's numbers will help me understand how much time I really spend on a project.

Aqua_Geek 16y ago
What level of granularity are you using in your estimates? Are you just calculating a number for the whole (eg "I think that will take 120 hours") or are you also breaking that down as much as possible? I've found that if I can get an estimate broken down into tasks of <10 hrs/ea then it actually turns out to be pretty close. That being said, the larger the project is, the greater the probability of underestimatitis. As soon as you hit 250+ hours, I've found estimates to become increasingly less accurate.
- Skroob 16y ago
  I've been doing the former, and it definitely needs to change. I'm obsessing more about tracking my time to help me with future estimates, for one. I will also try breaking down into finer granularity and hopefully that will help as well. Thanks for the advice!
msbarnett 16y ago
Personally, one thing I've found that helps with estimates is to think in terms of days instead of hours, and to assume a fairly low productive amount of hours (5) within each day when converting back. (Yeah, you'd hope to be productive for more than 5 hours in a given work day, but there are a lot of little things that steal your focus and eat a lot of time away from your project without you realizing it. Fail to account for them at your peril). The original estimate someone put forth for twitterific was 160 hours of development. Ask yourself, could you reasonably expect to sit down today and from scratch, have written something as polished as twitterific, in only 32 days? Knowing full well you will need to spend days banging your head against some problem that should have taken you 10 minutes but somehow cost you 6 hours, testing and fixing bugs, profiling and optimizing slow code paths, polishing interactions, tweaking animations, and going back to the drawing board when some piece of functionality doesn't quite feel right? The testing and tweaking alone can last for weeks in high quality projects, and 32 days only gives you 4.5 weeks from start to finish. It's absurdly low.
akeefer 16y ago
One common technique used by agile methodologies (yes, I know that word has a ton of baggage) is to estimate in terms of story points rather than actual hours, days, etc. You start out thinking of a point as "one ideal day of uninterrupted work" to use as an anchoring point, and then for any work you want to do you break that work down into stories that you can estimate work for. If the story is bigger than about 3 points, you break it down further; if you can't estimate it, you do more research so you can. The important part is not that the estimates match any number of hours per se, but rather than the relative weighting is about right, such that something you estimated as 3 points is, in actuality, about 3 times as much work as something estimated at 1 point, and all 1 point stories are roughly comparable in terms of work. What you then do is to empirically estimate the actual mapping of points to hours/days as you work by tracking your velocity. In a 40-hour work week, how many points do you actually get done? As you get better at estimating, ideally your velocity becomes more stable, and then you can map from points back to days in order to make scheduling decisions. We switched over project planning and estimation to that strategy on a fairly large project I was leading, and it helped give us much more accurate overall estimates. Now, that's all easier to do when you're working on a long-term project, you're familiar with the existing code base and the problem domain, etc. such that you can actually break things down into stories and do reasonable estimates. That said, I think that the general idea of point-based estimation is still useful for you: rather than trying to estimate hours or days, work on getting better at relative estimation using something like points, and then empirically measure your mapping from points to hours to determine your likely schedule and how much you should bill.

by Skroob 16y ago

Aqua_Geek 16y ago

What level of granularity are you using in your estimates? Are you just calculating a number for the whole (eg "I think that will take 120 hours") or are you also breaking that down as much as possible? I've found that if I can get an estimate broken down into tasks of <10 hrs/ea then it actually turns out to be pretty close. That being said, the larger the project is, the greater the probability of underestimatitis. As soon as you hit 250+ hours, I've found estimates to become increasingly less accurate.

Skroob 16y ago
I've been doing the former, and it definitely needs to change. I'm obsessing more about tracking my time to help me with future estimates, for one. I will also try breaking down into finer granularity and hopefully that will help as well. Thanks for the advice!

msbarnett 16y ago

Personally, one thing I've found that helps with estimates is to think in terms of days instead of hours, and to assume a fairly low productive amount of hours (5) within each day when converting back. (Yeah, you'd hope to be productive for more than 5 hours in a given work day, but there are a lot of little things that steal your focus and eat a lot of time away from your project without you realizing it. Fail to account for them at your peril). The original estimate someone put forth for twitterific was 160 hours of development. Ask yourself, could you reasonably expect to sit down today and from scratch, have written something as polished as twitterific, in only 32 days? Knowing full well you will need to spend days banging your head against some problem that should have taken you 10 minutes but somehow cost you 6 hours, testing and fixing bugs, profiling and optimizing slow code paths, polishing interactions, tweaking animations, and going back to the drawing board when some piece of functionality doesn't quite feel right? The testing and tweaking alone can last for weeks in high quality projects, and 32 days only gives you 4.5 weeks from start to finish. It's absurdly low.

akeefer 16y ago

One common technique used by agile methodologies (yes, I know that word has a ton of baggage) is to estimate in terms of story points rather than actual hours, days, etc. You start out thinking of a point as "one ideal day of uninterrupted work" to use as an anchoring point, and then for any work you want to do you break that work down into stories that you can estimate work for. If the story is bigger than about 3 points, you break it down further; if you can't estimate it, you do more research so you can. The important part is not that the estimates match any number of hours per se, but rather than the relative weighting is about right, such that something you estimated as 3 points is, in actuality, about 3 times as much work as something estimated at 1 point, and all 1 point stories are roughly comparable in terms of work. What you then do is to empirically estimate the actual mapping of points to hours/days as you work by tracking your velocity. In a 40-hour work week, how many points do you actually get done? As you get better at estimating, ideally your velocity becomes more stable, and then you can map from points back to days in order to make scheduling decisions. We switched over project planning and estimation to that strategy on a fairly large project I was leading, and it helped give us much more accurate overall estimates. Now, that's all easier to do when you're working on a long-term project, you're familiar with the existing code base and the problem domain, etc. such that you can actually break things down into stories and do reasonable estimates. That said, I think that the general idea of point-based estimation is still useful for you: rather than trying to estimate hours or days, work on getting better at relative estimation using something like points, and then empirically measure your mapping from points to hours to determine your likely schedule and how much you should bill.