


Can Software Schedules Be Estimated? 480
"A recent academic paper Large Limits to Software Estimation (ACM Software Engineering Notes, 26, no.4 2001) shows how software estimation can be interpreted in algorithmic (Kolmogorov) complexity terms. An algorithmic complexity variant of mathematical (Godel) incompleteness can then easily be interpreted as showing that all claims of purely objective estimation of project complexity, development time, and programmer productivity are incorrect. Software development is like physics: there is no objective way to know how long a program will take to develop."
Lewis also provides a link to this "introduction to incompleteness (a fun subject in itself) and other background material for the paper."
from a Consulting viewpoint.. (Score:3, Informative)
To accuratly plan a software release you must have the project, and all it's complexities and nuances down COLD. otherwise you are not giving an estimation, you are giving a guess based upon incomplete knowledge.
The question becomes, do or, can you, know the complete details of the project? In this, software development is NOT like manufacturing, but more like home construction.
Think about it.
Much more like manufacturing than physics. Mostly (Score:3, Informative)
The reason that estimates are always wrong are *1* unclear requirements, *2* changing requirements, *3* complicated user interfaces, *4* weak focus on testing.
I find *1* to be the biggest difficulty. The prinicipals of a software project like to say things like "Automate timeclock operations" but as a developer, you need *A LOT* of information to do that. When you ask questions like "I understand that you do not want to allow any changes to a pay period after the checks have been cut, but then what are we going to do when travelling workers report their hours late?" Management thinks you are being a pain in the ass, but if you don't get it right, your project will fail.
I agree with taking a realistic estimate and doubling the both the developement and the testing estimates.
Re:In all seriousness, this is the wrong place to (Score:5, Informative)
Fixed specs are much easier to engineer than those that continually change. You wouldn't easily engineer a bridge if the river banks kept moving.
I think experienced project managers know how to control the spec rather than the project. (I could be wrong - It's just what I've seen).
Re:Software Schedules (Score:3, Informative)
The standard multiplier used is PI.
There are also some interesting results of programming speed in the Prechelt's comparison of different programming languages: an article [ira.uka.de], a tech report [ira.uka.de].
One of the conclusions is that script languages such as Python or Perl are about 2-3 times as fast to program with than Java or C/C++, at least in the small projects. The script programs were also about half as long in lines. There were also some differences in the reliability of the solutions - Python and Tcl had a very good score compared to C, although the small sample size for C may give misleading results.
I'd personally be very interested to see better data for differences between C and C++. I've recently been involved in C again after a long pause, and it seems like an awfully risky language to program with. However, it may be faster than C++, on average, and the Prechelt's results agree with this conception.
Re:Of course they can be estimated. (Score:1, Informative)
Re:Software Schedules (Score:1, Informative)
If you have not done it before, use PI.
If no one has done it before, use PI squared.
The book 'Rapid Development' has an exclent chapter on this. It says that the first estimate could be 50% out either way. As the project progresses, revised estimates will offer a more accurate prediction.
Re:Of course they can be estimated. (Score:1, Informative)
For more articles on Software Estimation [software-engineer.org], check this page:
http://www.software-engineer.org/article_index.ph
Re:In all seriousness, this is the wrong place to (Score:3, Informative)
There also seems to be a professionalism problem in software development - programmers often deviate from the project spec to add things that they want to add, just because its fun for them, with no regard to the impact on the deadline or whether or not the feature is required and/or even useful for the project. Project deadlines for bridges would also often slip if some of the engineers kept deciding halfway through that it "would be cool" if the bridge pillars "looked like giant penguins" or something. "Real" engineers have the professionalism to realise that they need to stick to the spec. With software its not quite so clear that you absolutely have to, so (unprofessional) software developers spend too much time near the beginning of the project adding fun, cool, useless things instead of concentrating on what needs to be done. Then for the last two weeks before the deadline SOMEBODY ELSE (usually me) usually ends up picking up the slack and working 16-hour shifts to get the program ready for delivery.
I keep having fights with one of the developers here, who is a good programmer, but he has *no* concept of deadlines, time, or priorities. Even the *management* have started multiplying his development time estimates by a factor of three (its usually the other way round!). He's always like "I'd like to add this", or "it would be really cool if we had this feature", or "but we're going to need this eventually anyway" (for future future projects that don't exist yet). And its always "it'll take less than a day", or "it'll only take a day or two". And it ALWAYS takes several times longer than "a day or two". And these things add up, he just doesn't see it, a few days here and there soon add up to a month or two. I can't get it into his head that even if it "only takes a day", as he insists, that thats one day that we don't have to spare, we're already running late as it is. Its simply not possible to add features without pushing your deadline further back, and he just doesn't get that. Its unprofessional, and its frustrating.
My biggest problem as project manager just seems to be getting people to work on what they're supposed to be doing. It doesn't help either that my manager keeps finding other things for the programmers to do. Some of the developers are professional, and will just focus on doing their jobs without requiring nanny assistance, but some of them you seem to need to check up on several times a day to make sure they're not doing the things they *want* to be doing. I shouldn't have to do that.
Time / project management for software (Score:2, Informative)
In reading a book called 'Your Money or Your Life' - don't remember the authors (try Amazon) they talked about tracking fincances, and figuring out where the money was going had to be done before being able to plan for savings or doing what you wanted in life rather than letting bills, banks and credit cards run your life. You have to track your money before you can figure out how much it costs to do certain things, and before you can reallocate it to get the best bang for buck.
In reading a book called 'Introduction to the Personal Software Process' but Watts Humphrey he talks about first tracking accurately pretty much every minute in every day, each week and figuring out where the time is going before you can reallocate to important tasks. The major outcome of this is of course putting your time where it matters, and being able to figure out how long certain tasks and projects take based on history.
The lesson is to: watch what you do accurately, categorize and analyze, set your priorities and goals to reflect what you want to accomplish (project, product, whatever), plan and repeat until you know fairly accurately how long specific tasks in each project take, and how long certain projects take.
This way you can work on decreasing production times, work on important tasks first rather than leaving them to 'whenever' and determine where time is being wasted.
I think it is totally possible to estimate project times this way. It can be done if you are willing to put in the due diligence. If not, hey take a guess and multiply it by two -- then make up excuses until its done (way less stressful I'm sure).
m
If you have certain preconditions, then yes. (Score:3, Informative)