Estimating Software Development Costs? 53
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!"
Wideband delphi ... (Score:2)
http://www.google.com.au/search?q=wideband+delphi [google.com.au]
The simple fact is, I cannot estimate for you. I can only estimate for me.
Of course, you would need to get a group together to use it. You may be able to use some of the basic principles however.
This is why we don't like MBAs. (Score:4, Informative)
And no, we do not think that MBAs are evil. They are just illinformed about what programmers do, and still like to take the dissisions that programmers should take. As you've just demonstrated. (No, asking slashdot, giving so little information that it is a joke, is not "letting the programmers deside")
I didn't like the old subjet line so I changed it (Score:1)
However, there is a reason why people say to extrapolate from past results. You can only have a sense of time once a team is in place. It is like asking how fast can a car go. Depends on the type of car. Some cars don't run at all.
Another way to think about it is: how much time do you have? Get a single programmer that is reasonable talented and reasonably easy to work with. Scale down to the absolute minimum application required to show someone. Get her to build it. Look for something no longer than a three week full time effort. Be available to provide direction a couple of times a day.
A decent coder at $50/hour * 3 Weeks * 40 hours per week = $6000. Feel free to play with this equasion until you have something you like. You can find university coders that are quite good willing to work for less, but you are competing with their classes and projects. You can find freelance people willing to work for less, too, but you want to be sure of the qulity of their work. If the application is simple, you can possibly get away with less time, as well.
Adam
Re:This is why we don't like MBAs. (Score:1)
No offense to the original poster, but I will bet a pound to a penny I know what will happen next.
He will take the estimate of the dude who says "seven months".
He won't bother absorbing the other 7000 words of Slashdotters' input.
He will take this quote to his professor.
The professor will then give him a good grade and praise him for thinking out-of-the-box.
This positive reinforcement then makes him not bother to understand the deeper concepts at work in Software Engineering. But what the heck, he has an MBA and an assured future!
(BTW, My tongue is most certainly in my cheek!)
Re: (Score:3, Funny)
Bad Voodoo (Score:3, Interesting)
As a programmer, I have long been troubled by the fact that the primary guages for success or failure on software projects are the schedule and the budget, the two items that programmers have the least amount of influence over.
Expertise (Score:4, Informative)
Obviously, your descriptions lacks details to make even a vague estimate of costs. So here are some general guidelines and things to consider.
If the 3 needs you specify are filled in independently, your project is bound to fail. That is: if front-end and database are built independently, the integration need is bound to be the most expensive. Only way to reduce integration costs is having a damn good specification of what you're looking for and some damn good project manager with a damn good team of coders, that can cooperate. (That, or a one-man-team that's proven to be up to the job.)
Porting efforts tend to depend on the size of the code base, and the ability to find a skilled porter. To a lesser extent it also depends on quality of the code and documentation. But I'd say size is the major issue here, keep things small.
Well, anyway. My advice would be: get someone that can give a good estimate, 'judged on past projects.' If that's not possible or not satisfactory, just determine market value, based on offers of different (sub-)contractors.
Oh. And there is no such thing as a scientific formal analysis that yields code size/cost/time based on a problem description. Nothing in software engineering (or elsewhere) has an accuracy that's within a factor 5, so consider these techniques useless. If you don't have the expertise, go look for people that have.
--
The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in: we're computer professionals, we cause accidents -- Nathaniel Borenstein
Hmmmm........ (Score:2)
as for the rest of it, do you know how long not to long is?
Your asking the how long is a piece of string question.
Well from what you've said, the database piece of string is quite short in comparrison to the other two bits.
The UI, is probably the next biggest thing
and in my experiance intergrating the the third party app is the largest and most risky piece of work.
So, I'd say it's going to take at least twice as long as you would want it too.
Market Programming (Score:2)
Cost Estimate (Score:3, Insightful)
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.
Quick guidelines (Score:5, Informative)
2) You need a detailed implementation specification, which should probably be written by someone with technical experience and at least some knowledge of the application's intended use. The person(s) who write this should be able to estimate how long it will take to complete.
3) You need to double the amount of time the folks from #2 give you as an estimate. If you didn't spend a lot of effort on #1, you should probably triple the estimate as you will be adding features that will render most of #2 obsolete.
Re:Quick guidelines (Score:1)
I agree, but don't make your programmers do it. You'll find that most of them hate estimating. Most of them suck at it. Even if they are eager, they'll be just as inaccurate as someone who doesn't know programming.
If you do a lot of this, it's best to have estimating specialists as part of the organization.
Re:Quick guidelines (Score:4, Informative)
1: Against each element assign a Risk.
2: Using the risks and the estimates and calculate the 95 percentile for a normal probability and quote this.
I can't remember the maths at hte moment (it's been a while). but something like
A takes 2 weeks, 1.5 with a fair wind and 4 if where in the shit.
B takes etc......
plug the numbers in and you get a probability curve for when the work will be done by.
Pick the 95% change of getting the work done and use that.
Re:Quick guidelines (Score:1)
don't move up deadlines (Score:2)
'Hey look they put together a functional prototype in a few days, shouldn't take them that long to polish it off. You'll have it tomorow.'
Re:Quick guidelines (Score:3, Insightful)
Regarding #3:
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:Quick guidelines (Score:1)
a day or so design,
One week of coding,
a few days testing
a few days for documentation (test scripts &co)
one week for UAT type testing
coding is only a fraction of the work.
given there's a minimum overhead to any coding, 1hrs coding easly becomes 2 days.
Rough Estimation (Score:3, Informative)
Database - About 2 weeks with populated test data.
GUI - About 6 weeks.
Interface to other system - About 6 weeks.
That's 14 weeks, so double it to 28 weeks. Your project will take about 7 months to complete with one developer.
Re:Rough Estimation (Score:4, Insightful)
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.
Re:Rough Estimation (Score:3, Interesting)
You're right that the poster doesn't supply NEARLY enough information, but on the other hand, I think that 7 months is about right given the sketchy details provided.
I'm currently working on a project to build a customer relationship database that is replicated to salespeoples' computers. The spec was for 6 weeks of development time, and I'm going to have it done inside of 5 weeks.
Good software doesn't have to take years to build, or piles of money. You just need to choose the right tools for the job, plan a good specification about what the application needs to do, and IMPLEMENT the frigging thing. A lot of people now-a-days try to over-architect the app before any code gets written. I believe that properly designed code can be refactored as it's being built, getting the product out the door quickly, and implementing new (changed/additional/etc) features in later versions.
Re:Rough Estimation (Score:1)
No offense, but it could also be 7 weeks or 7 years. As others have pointed out (and you admit), there is not nearly enough information to make a reasonable estimate.
The only thing to do (as others also have pointed out) is to find an experienced developer who also has experience with requirements analysis, and let him/her analyze the requirements and come up with an estimate. And then you are probably still way off...
Also, consider if there are any security requirements. If so, this could easily double or triple the development time, since security is very hard to get right, and a system that is only partially secure typically fails the requirement.
Another tidbit: the industry average is about 10 lines of source code per person, per day. I know it seems ludicrously low, but it includes everything, soup to nuts. Of course, that now shifts the problem to estimating the number of source lines needed, which is hardly any easier than estimating anything else, so that does not help a lot...
Re:Rough Estimation (Score:2)
Shame... Before the dot-bomb, it was 20. :-)
Re:Rough Estimation (Score:1)
Complexity must be known a priori (Score:2)
But what's important is knowing, in at least a vague sense, how many "bits" you need. This will help you realize how many branches (if statement, switch statements, and so on) you will need. In the above example, if you have two types of cars to program representations for, your code will probably have something like:
if (car.type == type1) then do X
else if (car.type == type2) then do Y
Branches, whether they come from if statements, switch statements, loop structures, or class polymorphism, are the basic building block of the complexity of a program. To extend on the above example, if each car can have two different types of engines, then the code will look like:
if (car.type == ctype1) then
if (car.engine.type == etype1) then do X
else if (car.engine.type == etype2) then do Y
else if (car.type == ctype2) then
if (car.engine.type == etype1) then do X1
else if (car.engine.type == etype2) then do Y1
end if
Here, you can see how the complexity has doubled by adding a single extra bit of information to each object.
If you are dealing with a data structure that has sixteen fields, then you have 2^16 = 65536 cases to worry about! However, it is often the case that some of these fields are not independent, so complexity will be reduced. For example, if you have two types of vehicles, car and bicycle, and you have a field representing the engine type, then you don't truely have two bits of information, because bicycles don't have engines. In this case, the number of branches will be represented by adding instead of multiplying. This will look like:
if (vehicle.type == car) then
do W
if (vehicle.engine.type == type1) then do X
else if (vehicle.engine.type == type2) do Y
else if (vehicle.type == bicycle) then
do Z
end if
Here we have four things to worry about. You can use the basic rules of information theory as a guide to understanding the complexity of your project.
Usually, however, the project is already well underway before the complexity is understood to any significant detail. This is the reason managers use "guesstimates" and such, because they really don't want to, or don't have the time to, understand the real complexity of the project. This isn't really blameworthy, since much of the above task is not a manager's job.
But you should keep in mind that you will never really know the complexity. People that have done many projects of a similar nature can often estimate the complexity without too much effort, but this is because they are already familiar with the situation. If you are tackling a new problem, all bets are off. Prior experience, in this case, gives you nothing.
break it down a lot more (Score:1)
1. Find an experienced developer
2. Create a more detailed technical specification
3. Define 'interface with a custom mapping application'
In addition, you're describing the wrong parts of the program. It matters less how big the database is, and what you're going to search on:
a. last name only?
b. date within the last 2 weeks?
c. both?
d. pizza joint within 2.5 miles of given address?
As you can see, we can't really tell you...in addition, the user interface is a whole other animal. It's quite likely that an app can have plenty of screen space/input options on a Palm, and none on a phone. Therefore, a 'port' is more like a rewrite.
What kind of input? First three letters of a last name with autocomplete? select from a dropdown list? We need a better understanding overall, and unless you drop all the details in slashdot (and good luck getting us to sign an NDA), you're not going to get much.
I disagree with the post that says '1 developer - 7 months.' I know people that could do this in a couple weeks, if presented with a decent spec. Of course, these folks are one in a thousand, and it's up to you to find them. If you can't even describe your goals just yet, you're not going to be able to find the right developer.
Re:break it down a lot more (Score:1)
One of the problems involved is that this guy has no experience programming. How is he going to know who's experienced and who isn't? I know people who are just barely competent at their jobs after 10+ years of practice and some real wizards who have only been working for two or three years.
time to download the palm/pocket PC SDK... (Score:2)
To manage programmers, you have to know *something* of the things you manage.
That application could be anything from 2 people/1 month to 6 people 6 months (and beyond!) It depends on the skill of your programmers, the work ethic and worthiness of your project (an exciting project seems to go quicker, even with true professionals, as there's this urge to see the result.), and the scope of the project.
The best way to understand is to start fiddling around with the software itself. I know, it takes time, but you just need some basis of what you can and can't do.
Rules of Thumb (Score:3, Informative)
The other is similar, IIRC from a UCLA project: "double it and add six months"
Everyone already knows the "90% rule of software" - the first 90% of the work takes the first 90% of the time; the last 10% of the work takes the second 90% of the time." I would add that the last 1% of the work will take the third 90% of the time. This is very, very true.
Many Open Source projects either demonstrate this or never get the 2nd and 3rd parts done - because these are the parts where the errors in the UI definition are found and fixed, often requiring complete rewrites; and the final tweaking is even harder. Like any art, the closer to perfection you want to get, the more work it is to get there. It takes just as much (or more) time to polish the last eensy bit of shine as it did to rough out the piece.
I have found the following:
1. Larger projects are easier to get right, for two reasons.
a) they must be broken down to smaller units and thus are usually more completely defined.
b) If you're reasonably good at such things, the uncertainty of the estimate on each unit is about even, so while some units go over, others go under. In a large project this can be a wash.
2. In practice, using good large-team software engineering methods, about 1/2 of the total effort expended is in the initial design - which is also where some 80% of the bugs are created and must be found. Only about 10-15% of the effort is in coding, and perhaps 30% in SW QA, which must start in the design phase.
These factors are ignored at your peril. Many programmers are used to conceiving something and cranking out a working rendition overnight. However, turning that piece of basically-running code into something that will robustly handle all possible idiot inputs and attempts at cracking will require triple that time at least.
3. In general, if you can break problems down to a tree of trivial projects, you can thumbnail the estimates for each of those fairly easily. If a piece involves work you're not familiar with, you can ask others who are familiar with that piece and plug it in or further break it down. Units of one to 3 days are about right (or 4-24 hrs.)
4. Making it smooth and glossy so that people actually want to use it will require much more. The original piece of code can only be described as a 'proof of concept'. This is like the difference between a Ford Model T (with hand spark advance) and a recent automobile. There's a lot of engineering between those.
5. Look into "Extreme Programming" [extremeprogramming.org] - this appears to be a very good way to manage projects the way they really work, though I haven't actually run a project this way.
Having said all this, I've been pretty successful in projects up to about 10 people with myself and about 1.5 additional staff spending a total of (in one example) about a month breaking down a client-server system based on a well-understood set of algorithms to a very detailed project tree, with nodes that amounted to a few person-days a piece. This worked out to a project estimate of six person years. Of course, management screamed, but we got sign-off, and while many things changed due to company problems the parts we were allowed to build according to plan worked out very close to the original estimate. In fact, the parts they tried to short-circuit and ship early were finally fixed in about the original timeframe, with much customer unhappiness in the meantime.
I left the company shortly after.
Here's one (meta-) answer (Score:5, Informative)
Yeah, it's a lot of hard work. Deal with it.
Good, but not great (Score:2)
The things I'd change:
Chances are, debugging took from 100% - 200% of the time it took to write the code in the first place. This has to be a line item in the schedule, and it will probably be the largest line item.
Sweet jesus! Spending this much time debugging is a bad sign. If you're going to be spending 50-66% of programming time on something, then spend it on automated tests. The best way is to write them before the code, and not in a big lump, either. Write one little test, then write the code to make it pass.
If you spend the time on automated tests instead of debugging, then you won't just finish with a solid program; you'll also end up with a giant suite of tests that makes sure you never break anything.
Put integration time into the schedule.
Sure, putting integration time is better than the typical practice where everybody covers their ears and shouts, "la-la-la-la" when somebody brings this up.
But better still is to make sure that integration happens all the time. It's perfectly possible to check in code at least daily (I check in on average every 20 minutes or so) and to have shippable versions at least once a week.
Really good cooks clean up as they work, so they kitchen is always in pretty good shape. Programmers can learn from this.
The standard format I use for schedules is so simple you can memorize it. You start with just seven columns...
It can be simpler. The Extreme Programming style is to write the name of each feature on a card. Each card is given an estimate of 1, 2, or 3 points; that number is written on one corner of the card. Points are arbitrary, but the units should work out so that a team can do 5-20 points every (generally one-week) iteration. Cards that are bigger than 3 points are torn up; new cards are written that break the big feature down into lots of little ones.
Then the team does an iteration. However many points they get done, that's this week's "velocity".
Which cards to do first? Well, that's a business question, not a technical one. Ergo, the business people should put the cards in order by business value, and programmers should just take 'em off the top.
When do you release? Well, that's a business decision, too. I like putting special colored marker cards in the pile called "release 1", "release 2", etc. The business people can put those where they want.
What's the schedule? When somebody asks, hand them the cards, tell them your current velocity, and let them count their way down the stack to whatever point they are interested in. If they don't like the answer, tell them they are welcome to a) hire more staff, or b) rearrange the cards until they get an answer they like better.
This sounds glib, but it works. I recently got called into a project, already late, where a client handed me a vague 1-page spec for a subsystem and said, "You can have all this done in 5 weeks, right?"
Rather than laughing, I led him through the put-it-on-cards exercise and started working. In the end, we shipped on time, but with only half the original features that he asked for. But since he made all the choices about what to work on when, he wasn't pissed, he was delighted!
Re:Good, but not great (Score:2)
Traditional methods would say you spend more than 50% of your time doing analysis and design; do you want to get that far into the project before you know how long it's going to take?
XP would say Big Design Up Front doesn't work, but the Planning Game (with "user story" cards as you describe) does. I understand how that works for a single iteration, but not how well it works for a substantial (more than ten staff years) project.
I need to think more about this. (Check my Slashdot journal [slashdot.org] to see if I follow up there.)
Re:Good, but not great (Score:2)
Agreed. What I meant is that it's a step away from running a project on bullshit. Eventually, he'll probably realize that there's no good reason to do the detailed design for next year's features before you start next week's features. Then he can take a hint from the just-in-time manufacturing industry and move towards just-in-time design.
XP would say Big Design Up Front doesn't work, but the Planning Game (with "user story" cards as you describe) does. I understand how that works for a single iteration, but not how well it works for a substantial (more than ten staff years) project.
You can think of XP as self-similar across time scales. The basic behaviors (planning, designing, coding, testing, refactoring, integrating, getting feedback) should happen more or less continuously, even on the scale of an individual hour.
So a a release planning meeting (which might happen every 1-3 months) look a lot like an iteration planning meeting (which happens every 1-3 weeks). Which in turn looks a lot like what happens with an individual task. The granularity gets smaller, but it feels very similar.
Or another way to look at it is that after the first iteration is done, an XP project is in maintenance mode. Ergo, you could say that the main difference between a 10-person, 3-month XP project and a 10-person, 3-year one is that the latter is just longer. This means you have more (more releases, more tests, more code, more confidence in estimating, more changes in requirements), but it's essentially the same thing.
Does that help make it clearer?
talk to other students (Score:2)
If your school has a software engineering program, you're in luck, the higher level students should be very good at estimating time involved in programming stuff, but only after you work out what your requirements are.
If your school has a computer science or computer engineering program, you'll probably be able to find a lot of people willing to guess at how long it will take, and they probably won't make you work out your requirements. Of course, you'll have to take their estimates with a large grain of salt.
If your school has none of these programs available, then you'll have to go bother random students at another near by school.
Bad idea... (Score:2)
I very much doubt that. Most SE students have never worked on a serious project in the real world. That's why they're students, not experienced developers. They will probably have little or no knowledge of realistic risk assessment, and the largest project they'll ever have worked on is likely to be a project of a few weeks with just themselves or a small team on it. Under those circumstances, even the brightest student is just going to be plucking a random number from the air.
Re:Bad idea... (Score:2)
I know that truth in names in education is hard to come by, but if the major is software engineering, and they're not working on large projects, thats pretty bad.
Re:Bad idea... (Score:2)
I appreciate your point of view, having been there myself, but I think we're coming at this from different perspectives. The smallest serious project I have ever worked on in industry would be comparable to your "really long" projects. Much less than that, and it tends to be a sideline for someone rather than a major project. You might call a project with 1M lines of code large in industry terms, though some might disagree, and really large projects have hundreds of people on the project team and take thousands of man-years to develop. As you can see, there's something of a difference in complexity here. :-)
Of course, in this case, we really are talking about a fairly small-scale development. Still, the people who did the project management and estimation at places I've worked have generally been lead programmers as much as managers, and have had 5+ years experience of industrial scale projects as a minimum, often much more. In their time they will often have seen a dozen or more projects through from start to finish as a team member before progressing into project management. When you've seen a few diverse projects right through, you start to develop a feel for how long things will actually take, and unfortunately that feel is usually way out of synch with what the enthusiastic new grad will tell you.
Also, when you're working in industry, you are subject to pressures that aren't an issue for academic projects: your requirements are likely to be unclear at times, or to change as the project moves on, for a start. Learning to cope with these things is something all professional developers have to do, but it's not really something you can learn without actually being there and doing it, IMHO.
While I admire your enthusiasm and desire to gain good experience, and I think the sort of people you describe may well go on to become good project managers in due course, I stand by my claim that even a bright student will necessarily lack the experience to provide useful estimates for a commercial project under normal circumstances.
A few guidelines (Score:3, Informative)
First of all, realise that you are asking for a quick-and-easy way to produce information that normally requires several years of solid experience in the relevant industry to estimate with any accuracy. You cannot possibly do this alone if you don't have a background in programming as well.
With that very necessary caveat, here are a few guidelines that might be of use. After discussing the reasoning behind them, I'll come back to address the questions in the original post.
It can take very different amounts of time to get the same work done, depending on a few key variables:
These sound fairly nebulous, but there are some key points in each case that make all the difference.
1. How good is the spec?
First of all, you must have good specifications of the requirements. Start with something written in terms of the problem domain: what data will be in the database and how it will be used, what you want to be able to do with the UI, etc. Then have people who understand both the basics of the problem domain and the details of software development produce specs in software development terms based on your original requirements. Depending on the size of your project, this might be as simple as a database schema or two and a description of what the UI will look like. Around this point, someone experienced will be able to estimate how long the remainder of the project would take a typical team.
If you don't have a good requirements spec up-front, then clearly you won't produce very accurate technical specs from it, and the error in your estimates will be commensurately higher.
2. How much does the spec change during development?
This is a killer. Requirements often will change during the development of a project, either because the client's needs evolve over the lifetime of the work, or because you realise that the original plan was flawed and have to adapt. However, it takes significantly longer to adapt to changing requirements than it does to get it right, at least mostly, up-front. If your requirements are concrete at the start, and the most you're likely to need to change is a few details to adapt to things not working out as you first envisaged, your project will move fairly efficiently. If you constantly change things under your developers' feet (which is common if your original spec wasn't very good, for a start) then you need to double or treble the expected lifetime of the project.
3. How good are your team members?
Individually, a good developer can get an order of magnitude more work done than a mediocre one. If you get several good guys together on your team, and they're also team players and not prima donnas, you can estimate a much faster completion than you would from an average team. Of course, you'll have to pay these people significantly better, but they'll be more than worth it.
Incidentally, when you're forming a team, do get someone technically competent to gauge whether they know what they're talking about. A non-programmer is simply not qualified to do this, no matter how many clever books they've read or how many buzzwords were in their management magazine last week. Screwing this up is a great way to multiply the lifetime of your project by ten.
4. How good is the controlling process?
In a good, lightweight process, working with good people and good specs, you'll find that your team spends around 30-40% of its time planning and designing, a similar amount or a bit longer on testing and putting it all together, perhaps 10% on actually implementing the designs, and a few percent on overheads, mostly communication within the team to keep things organised.
In a bad process, you can ramp those overheads way up, easily wasting 50-75% of your developers' time on unhelpful paperwork and needless communications. Again, it pays to have a good project manager/management team, or to employ someone with good organisation skills if it's a one-person job.
So, there you have it. A good team, working fairly uninterrupted from good requirements specs and with a good co-ordinating process, will probably put together your software 50x faster than a team of poorly-trained code monkeys who are constantly messed around and following a heavyweight process that doesn't respond well to change. Of course, this doesn't really much happen; if you aren't smart enough to use good people and let them get on with their job, your project will join the vast majority: it will fail and be cancelled.
Back to the original questions...
With all of that in mind, it's hard to give specifics without knowing a lot more about your particular job, but I can give you an idea of what a typical, small-scale database application might be like.
UI work often makes up 50% or more of a project. Databases require some careful thought up-front, but tend to be fairly straightforward. Integration with an existing system is a bit of a minefield; as ever, if you've got clear specs to match against (and the existing system actually follows them, which is far from guaranteed!) it's fairly easy, but if you have to work things out for yourself due to lack of accurate information, this can be a big risk.
It sounds as though this project is fairly small scale. Assuming you have average developers, a small database would probably take a man-week or two to design and implement. A UI to provide basic input, searching and reporting functionality for a database of that size probably takes 2-3x as long as making the database itself. If you're only doing a simple transfer of data to another application, that might be done in a matter of days, but if you're talking to a big custom database app using non-standard protocols and detailed interfaces, it could take several weeks.
All in all, you're probably looking at 3-6 man-months to design and implement a typical application of the sort I imagine you're dealing with. Of course, then there are the overheads, particularly up-front requirements capture and the testing and QA time, so overall you're probably looking at 1-2 man-years of development from start to finish. Clearly this has to be a very random figure without a lot more details, but it's about par for the course designing small custom database apps with a decent team and decent tools.
As to your final question about porting: this really depends very much on how different the platforms are. If you know ahead of time that porting is likely to be a requirement, you can invest a little time during development to save a lot of time reengineering things later. Using portable tools and programming languages makes a huge difference here, and having people on the team with experience of the idiosyncrasies of each platform to be used helps a lot, too.
If you've done this well and your project requirements are amenable to porting, you might port successfully in 2-3 man-months. At the other end of the spectrum, sometimes things are so different that it really is faster to rewrite from scratch, though obviously you'll have gained a lot of insight the first time around so you'll generally get the second implementation done significantly faster than the original.
No past projects? (Score:2)
In my company we have developed for RS-232, DOS, Windows, Client/Server, WEB, WAP, PDA and Phone, and it usually ends up being my job to estimate it, or to estimate the bits nobody else has a clue about.
Estimating is seriously hard. People have tried all sorts of ways to simplify it (function points, for example) and it is still hard.
The first problem is that complex programming projects that are called "complete" in a reasonable time are actually compromises. Everyone starts with the idea of building something which works according to some (possibly vague) specification, but what gets implemented varies from that ideal by some amount of compromise.
The second problem is feedback loops. If I have 'X' functionality that I want to implement, sometimes I will think of a method of implementing 'X' which makes 'Y' additional functionality easy (Yay!), and sometimes my way will make 'Y' hard (boo!). This problem is somewhat behind the "we need a specification" camp, because if we write everything down first, then we can work on making our compromises in a structured way, choosing the 'X' implementation (that we think of) which makes 'Y' easiest. Alas, the more complicated (and hence more difficult to estimate) projects inevitably introduce requirement 'Z' after this just to screw it up. Or they are specified by bozo 'B' who just can't think crookedly enough. All of this feeds back (as good feedback should) into the first problem, of course.
Amusingly, our company was recently reviewed by a client for several projects and found to have a puzzlingly high development rate for each function point. It is my considered opinion that we achieve this partly by minimising the bureacratic overhead involved in specifying the system. This doesn't mean not doing a specification, it means simplifying it as far as is practicable for the project. Then the other part, is that we use talented programmers who deserve such specifications can independently make sensible implementation decisions during the project. Common sense is remarkably rare, but it is findable.
So you are up shit creek, because you don't know how to evaluate all of these side-effects. What that means is that you have to be conservative.
Conservative estimation is much easier. It takes a boring analyst around 2 days to design a screen (whateverthehell that is!), and it takes a boring programmer around 4 days to implement it. If it's a complex screen (lots of fields, say), double it. If it's very complex (lots of fields with lots of complex validation), double it again. If you want something that works reliably, factor another 2 days (times comlexity factor) in as well. Add 20% for project management. Add another 30% for implementation related tasks. Finally, add 30% at the end for fixing the stuff that you missed earlier.
Conversion to a 3G handset from a Palm OS device will take at least as much programmer and tester time as the original. Especially since Palm OS is mature and understood, and I don't know WTF a "3G handset" has running on it: Symbian? Java? Brew? Wince? PalmOS? You choose.
Hope this is some help!
some thoughts (Score:2, Insightful)
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.
Longer than estimated (Score:1, Funny)
Longer than estimated.
Incomplete Information (Score:2, Informative)
It's sort of like asking a building contractor, "I want to build a house. You know, a house. With walls, and ceilings, and windows, and don't forget some doors too while you are at it." The specification is so vague that nobody in their right mind will be able to give you an estimate based on that information.
Here is a method that I've seen used for estimating the length of a software project. As you can see, it'll require some amount of work.
1. Come up with a DETAILED design of the project. You won't know how long the project will take if you don't know what the project is. When you say "build a front end", that could mean anything from a single screen with a few buttons and text boxes, to hundreds of screens with graphs and report generators, and all the other bells and whistles.
2. Subdivide the project into a series of smaller tasks. Try and make each task as small as possible. Small uniform tasks are much easier to estimate that a large nebulous one. Don't forget to include non-programming tasks, like testing, integration, documentation writing, status reports, etc, etc.
3. For each task, try and assign a time value to them. If the task is small enough, you should be able to come up with a reasonable value based upon your judgment. If you are having trouble estimating a task, you may need to subdivide the task again into even small pieces.
4. Determine if any of the tasks can be done in parallel. If there are no dependencies between the tasks, then two people can work on them at once.
5. Assign developers to each of the tasks. Allow them to exam the estimates for their assigned tasks, and listen to their feedback! Obviously, if your project has a lot of tasks that can be done in parallel, then having more developers will make the project move faster.
6. Sum up the total time of the subtasks, taking into account tasks that will be worked on in parallel by different developers. This will give you a rough estimate of the completion date. Of course, since this is an estimate, it is likely that it will take longer (or shorter if you are lucky). If that is unsatisfactory to the "powers that be", you will need to cut features or add more developers (but only add developers if things can be done in parallel).
7. As the project moves along and tasks are completed, see if the time it takes for each task matches up with the estimate. If you see that tasks are taking 50% longer than estimated, you should go back to your original task estimates, increase them by 50%, and recalculate a new estimated completion date. Doing this early in the project will prevent the "powers that be" from being surprised when your project isn't shipping by the "ship date".
8. If new features are added at the last minute (which they always are), you will need to add more tasks, and more time estimates to your project. Keep in mind that changes may require revisiting previously completed tasks.
In summary, know what you are going to do, make a first order estimate based upon the tasks, and as the project moves forward, recalibrate you estimate based upon actual data.
Since this is for an MBA project, I'm sure you will be allowed some leeway as long as the method you've used appears reasonable to the professor.
Estimate (Score:2)
Without reasonably detailed specs no-one here can give you any meaningful answer...
You may not be evil.... (Score:2)
Slashdot is not the place to ask this question. Even if you had given us enough information - which other posts have already told you is not the case - developers are notoriously bad at estimating the amount of time required to do anything. We tend to confuse "simple" with "quick". I can't count the number of times I've seen a task and thought "That looks easy - I already know how to do that - I'll give myself a bit of free time and say 2 days". Then I find myself a week later still hacking out "simple" code - there just turns out to be a lot of it.
The opposite is of course also true - I've frequently been asked to solve a problem and thought "wow - that's really hard to do in a clean way. I gotta take a couple of weeks just to figure out how to do it - better say a month" when there's a nasty hack that can be implemented in an afternoon.
So, what is the evil answer to your question ? Get some hapless consulting firms (3 should be enough) to quote for the work. They will force you to specify what it is you want in a lot more detail ( a useful exercise in its own right), and make up a number. Ask for their hourly rate and you should be able to come up with a decent idea.
You should also read Steve McConnel's "Rapid Development" - it is full of fairly scientific ways of estimating software projects (and it's pretty readable even for a non techy), and you could do should read Cockburn's "Agile Software Development" book for ideas about how to break out of the "but I have to know how much it's gonna cost before commiting" cycle.