Can Software Schedules Be Estimated?

J.P.Lewis writes " Is programming like manufacturing, or like physics? We sometimes hear of enormous software projects that are canceled after running years behind schedule. On the other hand, there are software engineering methodologies (inspired by similar methodologies in manufacturing) that claim (or hint at) objective estimation of project complexity and development schedules. With objective schedule estimates, projects should never run late. Are these failed software projects not using proper software engineering, or is there a deeper problem?" Read on for one man's well-argued answer, which casts doubt on most software-delivery predictions, and hits on a few of the famous latecomers.

"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..

[Tadghe]

The reason that software development timetable "estimation" (guess is a better word) is so often wrong is that quite often you are not given enough information about the projecto accuratly pin down what your milestones are much less your final delivery date.

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

[ers81239]

As a software developer, I would have to say that a majority of the development that I have been involved in or been aware of is of the manufacturing variety. Most business sofware is a DIDO job. Data in, Data Out. Make some fancy forms and reports and you have turned a database into a 'billing' system or what have you. There aren't really any new algorithms needed. Of course, there are a ton of them in use in the database server, the network protocols, etc. But you aren't developing those, just using them.

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

[Organic_Info]

True but most experienced S/W engineers or Project managers know that most projects slip because of changes to/deviations from the original project spec.

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

[magi]

2) Take your best estimate , and double it and add 5 or something....

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.

[EllisDees]

Did you read the article referenced at the top? The problem isn't with programmers, but with the math that underlies all programming. If you have to develop an entirely new system, you can run into a version of the halting problem - that you cannot accurately know ahead of time how long it will take to transform your concept into a functional program.

Re:Software Schedules

[ayjay29]

I have heard that one too.

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.

[herve76]

For more articles on Software Estimation [software-engineer.org], check this page:

http://www.software-engineer.org/article_index.php ?name=Software+Estimation&category_id=15 [software-engineer.org]

Re:In all seriousness, this is the wrong place to

[SpeelingChekka]

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

[mikers]

I believe there is a way to estimate project time, but of course it is a learning process, experience matters and refinement of estimation techniques is the process.

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.

[soft_guy]

Software engineering is like any other kind of engineering. You *can* create a realistic schedule that you can follow. I have worked on a large number of software projects. Some hit their dates, others did not. I have identified certain preconditions that have to be met if you want to hit your date. (Not that these are profound, pretty much everyone would agree this is common sense stuff -- it's just that often times conditions aren't met which causes late projects.) First, the customer (whoever if calling out the requirements) can't be changing the requirments insanely. This one should be obvious, but I've experienced a large number of situations where management changes the basic premise of what they want regularly and are surprised when this impacts the schedule. Any external dependencies have to be met in the timeline called out in the schedule. I worked on a project where we had to deliver a server that talks to our customer's other servers using a proprietary protocol. The customer asks, "Can we have it by x date?" Our response, "Yes, if you can give us the documentation to your protocol and access to a testbed by x-y date." They delivered their end of the bargain (extremely) late causing us to be late. ("But you said you could hit the date!") Go figure! The third precondition is that the program manager should not be an idiot. This person needs to have the following characteristics. They need to be very technical. People who are former developers usually do okay. As a rule, people whose total background is as a marketing assistant or a receptionist(!) usually do not make good program managers. (The receptionist I had as a PM didn't do too bad because she understood that she didn't know anything about it and let me - the lead dev - call the shots.) This person should have been around the block a few times and should agressively track down any risky issue or "gotchas" in the process as soon as it is uncovered. This person should be tenatious in doing this. If you have those three preconditions met, then typically you can hit your date.