Estimating Software Development Costs?

Stu Lalison asks: "I'm an MBA student (but I'm not evil, I promise!) and am working on a business plan that involves having some custom software written for a handheld computer. I've done some research into estimating the costs involved in software production, but when estimating the time involved in writing the software, it usually says 'judge on past projects.' I'm not a programmer, so I don't have any past projects to judge on. I'm wondering if the Slashdot community can give me some ballpark figures on how long it takes a professional programmer to code different parts of a program. I've identified 3 needs of my application: a front-end user interface, a database w/ search function (of about 10 megabytes of data), and integration of both of these into a (currently existing) commercial mapping application. It seems like these aren't huge tasks, but getting (even a rough) handle on their actual complexity will help me greatly. Also, how much development time would be required to port an application like this from, say, a Palm OS device to a 3G handset? Thanks in advance!"

Comments

Cost Estimate

[the eric conspiracy]

it usually says 'judge on past projects.'

There is the clue to your answer. Hire someone who has done this sort of thing to give you an estimate.

Or you might try to go to a contractor and see if they will give you an estimate.

Re:Quick guidelines

[Maple Syrup]

Regarding #3:

"You need to double the amount of time the folks from #2 give you as an estimate".

IMHO, you need to double the amount of time and convert to the next-higher units. Because what you think is a "1 hour job" really will take you two days, and the "One week of coding" really will take you two months.

DAMHIK

Re:Rough Estimation

[Bitsy Boffin]

I hope the poster doesn't take your answer seriously. There is nowhere near enough information given to make ANY sort of judgement on how long it is going to take to do anything let alone finish it. We don't even know what the system is supposed to DO (asides probably something to do with mapping).

How do you know what the system you are interfacing with looks like, what protocols you're going to have to use, maybe you have to invent them, maybe you're gonna have to figure out some communication method between them.

Perhaps there is a framework for buiulding the GUI already there meaning programming takes 2 weeks, or maybe you have to do everything from scratch and programming is going to take a year.

As for the database, you don't know anything about the data - can't even begin to imagine where you got 2 weeks from.

some thoughts

[cheezehead]

First of all, you really need to know your requirements before you can even take a first guess.

Then, you need an architecture. After this is defined, you can divide the work into modules (or subsystems, or whatever the buzzword of the week is).

It is *extremely* hard to estimate anything until this is done.

Now, the good news is that if you can give an experienced developer a reasonable idea of what a module is supposed to do, you have somewhat of a chance of getting a reasonable estimate of the amount of time it will take. You see, good developers can actually estimate this quite accurately (contrary to popular belief). This is because they overestimate their own abilities somewhat, but this is compensated by the fact that they tend to give themselves some leeway ("I think it will take 2 weeks, so I'll tell them 3 weeks").
A potential problem is that a manager does not like the answer, because of planning and scheduling, and what the manager promised his boss. My favorite quote here is: "3 weeks? That's not a good enough answer!". My standard reply to this kind of nonsense is either: "I think it's an excellent answer, because it happens to be true", or "What do you think the right answer is?". Anyway, the risk is that the developer thinks: "Well, my own secret estimate is 2 weeks, so I'll just tell him that, to get him off by back". Then, of course, it takes 3 weeks after all. Sadly, we've all come to accept and expect this kind of stuff in the IT business.

From personal experience: I was asked to write a thin wrapper around a RDBMS API written in C. Since I had to familiarize myself with the API, I estimated 3-4 days, so I told management 1 week. I was asked if I could do it faster if I were to use C++ rather than C. I said no, because it wasn't the silly wrapper code that would take the time, but figuring out the darn API. Oh. Anyway, I was done by the end of the fourth day, so, on the high end of my own estimate, even though I have more than average experience in these kind of things. Everybody seemed really surprised that I managed to do it within the official estimate. The code did have one subtle bug that showed up the next week, but that was fixed in half an hour. Again, people seemed surprised that there was only one obvious bug in the code.

Anyway, after all this bragging, the point is: you can reasonably trust the estimates developers give you, but only after you give them a reasonable amount of input.