Re: a question on case/software engineering

[blahblahblah]

If you're interested in estimation, I'd recommend this book: Software Estimation: Demystifying the Black Art. I found it very enlightening, and have effectively used some of what I learned.

For the rates question, another book recommendation: Getting to Yes. I first heard about this book 5 years ago on perlmonks (software collectives vs. price of organizational license), and ordered it because the amazon reviews were so impressive. It got lost on my bookshelf until this past year when I picked it up, and it's been so interesting and useful that I regret not having read it sooner.

Joe

[user2000]

hi, thankyou for all your replies. the thing is that suppose a customer asks me for a custom job, i end up saying "cost/hour: $10, hours required: 10, total: $100". Now the hours required i select is a wild guess on my part to be honest. the problem is how do i accurately set the hours required. then how do i measure it? (i dont want to use a watch while i work). and once i measure it, if its more how do i tell the customer that i should charge him more?

[duff]

The only way to figure that out is through experience. You make your best guess and then learn from experience how good your guesses are and adjust as necessary.

Joel Spolsky has a product called "FogBugz" that started out as just a bug tracking tool but has morphed into much more. One of the more interesting things is that you can enter estimations of how long you think tasks will take, then as you figure out how long they actually take, there are tools that tell you how well you or your team are estimating. If you can list most of the tasks ahead of time, FogBugz can tell you a reasonable ship-date based on the estimated times and your past history. I've never tried it for single-developer use, but when I asked Joel about it, he said that there are some people trying it.

In any case, FogBugz has some interesting ideas to borrow from for estimating time.