Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Can Software Schedules Be Estimated?

timothy posted more than 13 years ago | from the now-stop-abusing-the-mozilla-team dept.

Programming 480

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

Sorry! There are no comments related to the filter you selected.

Moo (-1, Offtopic)

robvasquez (411139) | more than 13 years ago | (#2522282)

I'm a cow

no (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2522286)

no your not

Re:no (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2522296)

yes he are.


Software Schedules (4, Funny)

JohnHegarty (453016) | more than 13 years ago | (#2522290)

There is only two type of software schedules

1) As long as it takes.

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

It prefer the as long as it takes. Other wise you end up with something like Windows Me.

Re:Software Schedules (2, Interesting)

Organic_Info (208739) | more than 13 years ago | (#2522357)

"1) As long as it takes."

As long as it takes to get it right. This to a point is a barrier opensource S/W does not hit to a large extent as development is continual till no longer required.

An interesting question is when will Linux/*BSD development stop? Will it be surpased by an/other projet(s) or evolve to perfection?

Re:Software Schedules (3, Informative)

magi (91730) | more than 13 years ago | (#2522473)

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:Software Schedules (1)

memfrob (157990) | more than 13 years ago | (#2522497)

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

No, no... Take your best estimate, double it, and convert to the next higher units. (minutes->hours->days->weeks->months, etc)

Thus, a five minute project will take ten hours to finish, and a "two week project" will, in fact, take four months to complete.

In all seriousness, this is the wrong place to ask (2, Flamebait)

Junks Jerzey (54586) | more than 13 years ago | (#2522297)

The majority of Slashdot readers are students without any notable software engineering experience. Sure, not everyone here fits this description, but it's certain that there will be lots of hearsay, what-my-professor-told-me responses, and misguided personal theories based on blind idealism.

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

yatest5 (455123) | more than 13 years ago | (#2522305)

Because anyone who does know about software engineering is working his ass off trying to claw back some time on his 3 year late project ;-)

Re:In all seriousness, this is the wrong place to (2, Insightful)

Bobo the Space Chimp (304349) | more than 13 years ago | (#2522416)

You can develop properly, but you have to design modules with all specified functionality in mind -- no last second adding in "oh yeah, don't forget the login system" or "we're gonna want a WOW display attached to the processing so add in all these hack hooks at the last second into the core engine."

If you need that stuff, design it in from the start. Too many programmers worry about general design to make future expansion easier, while leaving out consideration for real, hard requirements that won't be implemented until later in the project.

And to avoid the problem with really bad bugs that are responsible for the (double it and add 5) estimation, take a little extra time to write exhaustive testing (as far as possible) of each module, indeed each function, to make sure it doesn't do something wrong when given values out of "happy path" input range.

Right place to Ask (2, Interesting)

maroberts (15852) | more than 13 years ago | (#2522400)

Like any public forum Slashdot has a wide range of readers, a large number of whom actually work in the software engineering field [myslef included].

Anyway my personal theory based on blind idealism is that it is extremely difficult to get an estimate for completion right; short term goals are fairly easy to predict, because you have most of the information you require to make those predictions, but longer term estimates are much more of a wild guess. I personally thing its a consequent of chaos theory - a butterfly flutters its wings in Brazil and your software project instantly takes another two years! More seriously small errors in estimating components of a large project can induce large errors in estimating the time and resources needed to complete the whole project.

Linux is right with its "release when ready" motto. Since it is impossible to tell when it will be ready over such a wide range of groups and interests, you have to pick your release moments when they happen, not try and force them to happen.

Slashdot readers are students? (3, Interesting)

Smallest (26153) | more than 13 years ago | (#2522417)

where'd you get that idea?

i've always thought most /. readers are programmers and IT people who come here to kill time at work.


Re:Slashdot readers are students? (0)

Anonymous Coward | more than 13 years ago | (#2522531)

You only have to read the comments on political articles to know the average Slashdotter is about 20 years old and clueless.

Time for a real Slashdot poll (1)

SeanAhern (25764) | more than 13 years ago | (#2522553)

Knowing, in general terms, what the demographics of Slashdot readership and postership (?) is would be a very useful thing.

Re:In all seriousness, this is the wrong place to (5, Informative)

Organic_Info (208739) | more than 13 years ago | (#2522427)

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

Actually.... (3, Funny)

Anonymous Coward | more than 13 years ago | (#2522453)

...the real reason estimating doesn't work is that there's no way to predict how much time programmers will spend reading Slashdot...

Of course they can be estimated. (5, Insightful)

Anton Anatopopov (529711) | more than 13 years ago | (#2522300)

But not with any degree of accuracy. Function point analysis is one method that has had some success. The key to delivering projects on time always has been and always will be RISK MANAGEMENT.

Software development is not a science in the normal sense. Designing large software systems is an art. It cannot be pigeonholed. Stroustrup has a lot to say about this when he describes the 'interchangable morons' concept in the 2nd edition C++ book.

Anyway, read Death march by Ed Yourdon, and the mythical man month by fred brooks, and antipatterns, any time someone asks you for an estimate say 'two weeks' and then bullshit from there on.

That is how it works in the real world. The numbers are essentially meaningless, but the bean counters and suits have to justify their existance somehow :-)

Can you imagine asking Linus when 2.5 will be ready ?

Re:Of course they can be estimated. (1)

maroberts (15852) | more than 13 years ago | (#2522333)

Can you imagine asking Linus when 2.5 will be ready ?
You mean 2.6 (or maybe 3.0) surely - 2.5 will be another development branch. I believe a 2.5 branch is to start Real Soon Now and therefore test releases from that should come every few weeks or so.

Re:Of course they can be estimated. (4, Insightful)

sql*kitten (1359) | more than 13 years ago | (#2522389)

Software development is not a science in the normal sense. Designing large software systems is an art. It cannot be pigeonholed

That's exactly the sort of attitude that has caused the sort of spectactular failures of software projects to be accepted as the norm. Software Engineering is *not* "hacking" or "coding" or "programming", it's *engineering*, like building a bridge or a skyscraper. Yes, those projects go over time and budget too sometimes, but they are the exception rather than the rule.

That is how it works in the real world. The numbers are essentially meaningless, but the bean counters and suits have to justify their existance somehow

The problem is endemic in the industry. The other Engineering professions require rigorous accreditation before they let practitioners loose in the world, like the PE (in the US) or the Charter (in the UK). But the software industry hires anyone, and lets them get on with whatever they do, with no real management or oversight or planning.

In a well analyzed and properly planned project, the actual coding stage is little more than data entry.

Re:Of course they can be estimated. (5, Insightful)

KyleCordes (10679) | more than 13 years ago | (#2522433)

This approach applies, more or less, sometimes MUCH less, depending on how well understood the problem domain is, how many times you have done it before.

If you're building your 57th e-commerce web site, which works roughly like the 56 you build before, you can estimate very, very well, and you can reduce coding to nearly data entry.

If you're solving a problem of unknown scope, which your team has not solved before, which the solution is not clear to, and analysis has revealed some but not all of the details, etc., then you are not very right.

Re:Of course they can be estimated. (2, Insightful)

keath_milligan (521186) | more than 13 years ago | (#2522436)

If the software industry were saddled with the same level of process that exists in other engineering professions, we'd still be using character-based software, the web and the internet as we know it today wouldn't exist and most business would still be conducted on paper.

Re:Of course they can be estimated. (5, Funny)

john@iastate.edu (113202) | more than 13 years ago | (#2522484)

Writing software is not like building bridges because halfway through the project some dumbass from marketing doesn't come down and tell you that concrete is out and so it needs to be a steel bridge. Oh, and those tacky cables have got to go -- the focus group hated them.

Re:Of course they can be estimated. (5, Insightful)

xyzzy (10685) | more than 13 years ago | (#2522438)

I agree with your risk management comment, and a later poster who mentioned fixing the endpoint, but I'm not sure I agree on your claim that it can't be pinpointed with any degree of accuracy.

After ~15 years in the industry, I've found that one thing that makes a huge difference is the experience of the team, and the familiarity between the actual engineers and the project management.

As you have experience solving a variety of classes of problems, you can predict with increasing accuracy the time it'll take you to solve later problems. And as your management sees you getting increasingly accurate in your estimates (based on past projects) they can create better and better schedules and estimates for the project as a whole, and have a better intuition for the gray areas of development, or the greener developers.

Projects that tend to go off into the weeds have included (in my experience) wholly green teams, wholly green management, or areas of development that are outside the areas of expertise of one or both.

Re:Of course they can be estimated. (1)

SLOGEN (165834) | more than 13 years ago | (#2522476)

Please explain to me how an estimate without a bound on the accuracy of the estimate is anything but a guess?

Re:Of course they can be estimated. (2, Insightful)

mobiGeek (201274) | more than 13 years ago | (#2522571)

Software development is not a science in the normal sense. Designing large software systems is an art. It cannot be pigeonholed.

An experienced software project manager can usually be quite accurate in estimation of effort for a well analyzed software project.

This, however, highlights a few problems in The Real World:

  • many (most?) software projects are ill defined.
  • many (most?) software projects are not analyzed properly prior to the start of architecture design and start of coding
  • many (most?) software projects are not resourced properly up front; resources are thrown haphazardly at a project once deadlines are quickly approaching
  • many (most?) software projects are given unrealistic deadlines prior to analysis being done
  • many (most?) software project leaders do not have the political experience needed to manage the business expectations of a project [most engineering schools have mandatory Management Sciences courses for their students. Most CS schools avoid Humanities courses...yes, I am a CS grad].
  • many (most?) software senior developers are not encouraged to get involved in the "business" aspects of software projects.

Am I too pessimistic? I don't believe so.

Are we Artists or Workers? (1)

egriebel (177065) | more than 13 years ago | (#2522307)

I think a relavant tangent to this is how developers view themselves. In the "professional world", many of my peers view themselves as "artists", meaning that they can't code unless the mood strikes them, their work can't be rushed, etc. The other camp (myself included) believes software development to be a creative process, which requires some time for the creative process, but shouldn't dominate.
But, this probably mostly applies to professional software development, not academic/government-type work.

so so true (0)

Anonymous Coward | more than 13 years ago | (#2522308)

can anyone say tribes 2?

No Chance! (1)

libertynews (304820) | more than 13 years ago | (#2522310)

I regularly try to estimate my time, and come in at 1/2 to 1/3 (or worse) of the actual time to complete the task, even when I try to take into account the 2x or 3x factor! There are just too many factors involved (for example, your development platform crashes and takes a day to rebuild and get up to speed). Or the problem is more complex than it looks on the surface -- alot of the time you never really understand whats involved in the project until you dig into it.

But of course the client doesn't understand these things, so when you submit a proposal for 3x what they expected it to cost they freak out. So you submit for 2x what you estimate and hope they will understand when things take too long .

Re:No Chance! (-1)

notbob (73229) | more than 13 years ago | (#2522444)

I have the opposite problem, I take usually 1/2 - 1/3rd of the time to get it done thats estimated... but my company has been doing straight billable hours for me, and have decided to f' me after 8 weeks of doing 3 people's jobs in 20hrs/wk and now to keep my job had to agree to 16 weeks of 50hr weeks at same money.

Shitty market... maybe I should keep my eyes open anyways, I really love monday mornings.

That is exactly the issue... (1)

_anomaly_ (127254) | more than 13 years ago | (#2522475)

...not taking the time to compose complete specifications for software engineering projects... at least that's what I've experienced. Most manager types want estimates without putting any work into it, which is when you run into BIG problems (BIG underestimates). The thing is, there is quite a bit of work that has to be done in order to even have an educated guess. Customer specifications, developer specifications, test planning, etc. Once these things are considered and drawn up, it forces you to consider the unforseen, and plan for the unforseen.
Unfortunately, I personally have never met a manager type that will allow you to put time into a project they don't know will be profitable or not.

Double the number, add one and raise the unit! (1)

Uriel (16311) | more than 13 years ago | (#2522317)

How long could it possibly take? No more than three days? 3*2=6 ... 6+1=7 ... 7..days..no..WEEKS. Yes. That's the estimate.

Two weeks? No, make that five months!

This is mostly joking, but if you have people changing the specifications while you are writing the code, it can indeed happen.

PHB:"When will it be done?"
Me:"It's been done twice already, but now it's done for the third time. Unless you change the specification again..."
PHB:"Didn't anyone tell you?"


Re:Double the number, add one and raise the unit! (4, Funny)

dattaway (3088) | more than 13 years ago | (#2522369)

We can get it done by next week! We can do this because we have just #defined a day as having 2000 hours.

Re:Double the number, add one and raise the unit! (1)

Bobo the Space Chimp (304349) | more than 13 years ago | (#2522454)

If that were only true. I once estimated I needed about 36 hours in a day to get in all the sleep and relaxation I needed to be happy.

Anyone know how to build a Director Xtra C/C++ .dll to manipulate the native point arrays, or just "call" a standard .dll therein from a Director script?

Rule of Threes (was Re:Double the number) (2)

isdnip (49656) | more than 13 years ago | (#2522467)

You're close, but I think you're maybe even too optimistic.

I learned this about 25 years ago, while at a startup that was trying to build a computer out of the then-hot 6502-class microprocessor. The company tanked, never fully delivering. The smarter folks there (alas, there were not enough common-sense smarts where needed, just comp-sci-smarts always looking for another feature) knew the real Rule of Three:

Take the amount of time you think it should take. Triple it. Then increment the unit of time.

So three days is nine weeks, two months is six quarters.

Double plus one is, well, just too optimistic. Of course there are a lot of people who understand a "rule of three" that forgets to increment the unit, so the rest is just quibbling.

But hey, Microsoft did finally deliver something labeled Cairo (X P)! Lessee, that was due in what, 1995?

And Linux, while ten years old, still manages its desktop (rendering, fonts, etc.) somewhat worse than the Win95 GDI did. Nobody's immune.

Re:Double the number, add one and raise the unit! (0)

Anonymous Coward | more than 13 years ago | (#2522554)

A real life example of the changing specifications:

A simple project I am currently working on required a simple answer from the client which only affects if I put a simple loop around a calculation to do it twice in the same run with differnt options or for separate runs to be made. All interior coding within the loop would remain the same. The answer was - "Yes, do both in the same run. And would you send the results to different files." The problem? Well a lot of routines before the calculation had to be altered to get relevent data to TWO files so the results listed would be meaningful when the two files go different directions. This increased the scope of the work and blew the completion date (but in this case the client did not mind since they were getting what they wanted, fortunately).

How you write up some steps of the project is also very important. The client wanted the software completed by the end of October which was a doable date. However there was a client review step that was to be one week long followed by a two week completion step. The client is now approaching four weeks for their review and it is also now November. Fortunately I was wise enough in writing the schedule to make the end point two weeks AFTER receiving the clients review results.

Moral of the story is that estimating completion dates is impossible when there are outside people involved who can do what THEY want, when THEY want, to the project.

Sure they can... (3, Interesting)

Mike Schiraldi (18296) | more than 13 years ago | (#2522319)

As they say, the first 95% of a software project takes 95% of the time.

And the remaining 5% of the project takes another 95% of the time.

I don't think so (1)

segmond (34052) | more than 13 years ago | (#2522321)

I see software development as solving a mathematics problem, Can you estimate the length of time it would take for you to solve a problem? prove a theorem? I don't think so. Hence no! The problem is that many people are still reinventing the wheel. It is very hard to imagine that 99.9999% of the software that will be written tomorrow are revolutionary. They are nothing more than evolutionary, thus they should be grab libraries/routines for a good chunk of 80% of the code and tie it together. But such doesn't happen...

Yes but No (1, Insightful)

Anonymous Coward | more than 13 years ago | (#2522324)

If you want to keep the suits happy, Its easy, take the time you think it will take, multiply by two and add 10%.

Now when it comes to the actual work, forget it. Unless your project management is extra tight, which is unlikely from all the places I've ever seen, you will have too many unknown variables, such as:
  • That hot new developer you just hired turns out to be clueless
  • The specs were badly written, or your customer changes the specs mid-project
  • You can never factor in testing time properly (Trust me, I'm a tester). See below.
Especially when it comes to testing, too many project managers think you can just say "Oh sure, a twenty page testplan for that module will take one person three days. So we'll allow two weeks of testing per build, at three builds" This is total BS, because frankly, you won't know how many bugs are in the product, and therefore how many builds it will take to test the product, until you actually test it.

Sure, you can get an estimate, maybe to about 30% of the actual time it will take, about 60% of the time. Its certainly an inexact science though.

from a Consulting viewpoint.. (3, Informative)

Tadghe (18215) | more than 13 years ago | (#2522329)

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.

Re:from a Consulting viewpoint.. (0)

Anonymous Coward | more than 13 years ago | (#2522474)

This also makes an assumption that the requirements do not change, and they always do. A new version of your database becomes available which breaks things or adds features the users get a new version of some piece of software that you have to integrate, even though your 70% done with integrating the old one. Personally, I think any software estimate that is over a couple of months is a lie.

Re:from a Consulting viewpoint.. (0)

Anonymous Coward | more than 13 years ago | (#2522519)

As a consultant arent you supposed to *know* what to ask so you can get a clear picture of what needs to be done? That is the whole point of software engineering, you try to nail as much of the requirements and design first, then you code and test. If you did your job correctly, then project estimation is almost trivial. You also have to let the customer know that any mid-life changes to the original design *will* set back the project timeline significantly. This will force them to think about what they want up front and stick to the design later. Of course its almost invariable that some part of the design will change mid-code, but you can add a "fudge factor" to account for stuff like that. Also, if you design the software correctly, then mid-code design change effects can be minimized. Coding the project *should* be a small part of the entire project. More time should be spent up front in nailing the specs and design. This will make the coding part trivial.

my two cents.

Re:from a Consulting viewpoint.. (5, Interesting)

markmoss (301064) | more than 13 years ago | (#2522534)

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 bulk of the work of programming consists of getting all the complexities and nuances down cold. Once you really and completely understand what is required, coding is trivial.

This leads to a thoroughly unrealistic method of estimating software costs:
1) Work for months on the specs.
2) Get the customer to sign on to those incredibly detailed specs, even though he doesn't understand them.
3) Go and code it, no spec changes allowed.


The article mainly talks about the mathematics of estimating complexity. This is a lot like the proof that you cannot determine when or whether a computer program will end -- it's true for pathological programs, but it has little relevance for the real world. You try to write the code so the conditions for the program to end are clear. If it gets into an endless loop, you probably got a conditional expression backwards and you'll recognize it immediately once you figure out which loop is running endlessly... Likewise, there may be well-defined specifications for which it is impossible to estimate the coding time, but the usual problem is poorly-defined specs, which obviously makes any estimate a guess.

AZ Diamondbacks Win the World Series !!!!!! (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2522334)

The Arizona Diamondbacks Win the World Series !!!!

The Arizona Diamondbacks Win the World Series !!!!!

The Arizona Diamondbacks Win the World Series !!!!

and did I mention..... The Arizona Diamondbacks Win the World Series !!!!

Re:AZ Diamondbacks Win the World Series !!!!!! (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2522452)

What World Series?

As far as I know there are only American teams playing it.

Fixing the endpoint? (3, Insightful)

sphealey (2855) | more than 13 years ago | (#2522340)

Very large and complex projects do get completed, sometimes even on-time/on-budget. Examples include skyscrapers, nuclear submarines, aircraft carriers, power plants (whether conventional or nuclear), oil refineries, B-747/A-320, etc. And all of these systems nowadays have a software component as well.

So the easy response is that bad management in general, and bad project management in particular, is responsible for software project failures. While this is no doubt true, the next question has to be, why do software projects have such bad project management?

I don't have a good answer, but one thing that occurs to me is the lack of a fixed endpoint. When an oil refinery ships its first load of POL, it is complete. When an aircraft carrier launches its first plane, it is complete. But the amorphous and mallable nature of software means that it is hard to define an exact endpoint, and very hard to avoid changing the definition of the endpoint as the project proceeds. So things keep "creeping" along until disaster occurs.


Re:Fixing the endpoint? (2)

blang (450736) | more than 13 years ago | (#2522446)

Maybe it's harder to access slashdot, and taking care of your personal correspondence, play some game, surf around for news, etc. if you're a construction worker on the clock? Something that makes the estimation much easier for a contruction boss.

Re:Fixing the endpoint? (3, Insightful)

KyleCordes (10679) | more than 13 years ago | (#2522450)

Note that many of the kinds of projects you mentioned also sometimes have cost and time overruns of remarkable size.

Note also the enormous difference between building the first 747 / skyscaper / nuclear submarine and the 15th or 1500th of each.

This is why software projects fail (2, Insightful)

dybdahl (80720) | more than 13 years ago | (#2522478)

When you construct a house or a power plant, you are in a business with subcontractors, that can take some of the risks. It is generally accepted to set a fixed price, because the procedures that are involved, are mostly known.

In software, however, most projects do not rely on known procedures. It is fairly easy to estimate the costs of creating 1000 different window layouts, which is a known procedure, but it is a very difficult task to estimate the costs of implementing the layouts.

If software would use as much energy on estimating each new task as construction projects did, developing software would be extremely expensive. Just imagine that you had to do a while-loop according to an ISO standard, and another while loop according to another ISO standard, because the two while loops were in different functions that were categorized differently by a third ISO standard. Instead we hire a bunch of programmers and make them program themselves. Sometimes we do it a little more complicated, like Open-Source, Xtreme Programming etc., but it's still a bunch of programmers hacking around.

The trick is to manage it anyway - and that's why managing software projects will always be risc management and not very predictable.


Re:Fixing the endpoint? (1)

Bobo the Space Chimp (304349) | more than 13 years ago | (#2522483)

Those systems are not done in six months, a year, or a year and a half. Many computer projects are done on the Herculean Effort schedule, all the while pretending to be on a well-defined develop/test/refine cycle.

Re:Fixing the endpoint? (2)

Reality Master 101 (179095) | more than 13 years ago | (#2522509)

I don't have a good answer, but one thing that occurs to me is the lack of a fixed endpoint.

That's also a failure of management. All projects should have a requirements spec that describes exactly what the system is supposed to do.

I think the fundamental problem is that people don't want to spend money on all the "non-coding" documentation. Good documentation can take half the time of a project. It seems so much more "efficient" just to put a hoard of programmers on the project and crank out code, but it ends up costing a lot more.

Well organised software projects.... (0)

Anonymous Coward | more than 13 years ago | (#2522346)

have resonably predictable schedules. Badly managed prjects don't. Mozilla is badly managed. hence, it is very. very, very late.

The reality steps in (2)

forgoil (104808) | more than 13 years ago | (#2522349)

Yes, you can guess how long it could take, and no, there is no formula for it. I can have a great day and produce 10x as much as usual. I can be lucky and my first guess of how to do it is correct, or I can take the wrong one and loose a week. You might predict for some kind of generic person, but I know for experiences that there are very large differences between how fast different people produce code/documents etc.

So it's all a loss? Nope, but you have to remember that it's not an exact science. It involves replanning, knowing your work force, letting the work force plan on their own, more replanning, experince, guesses, and whatever it takes. Honesty is also high up on the list, and not trying to do huge amounts of work in one go. Heck, there is so much about this subject that it would ages to describe them. My suggestion is, go out in reality, work, and learn.

Projects != R&D (2, Insightful)

TheKodiak (79167) | more than 13 years ago | (#2522350)

Straightforward implementation, no matter how complex, can be scheduled accurately. Developing new technology cannot.

Re:Projects != R&D (0)

Anonymous Coward | more than 13 years ago | (#2522371)

If the only part you want to schedule is the actual development work, I.E not included specifications, testing & roll-out, yeah, I'm sure you could get a pretty accurate estimate overall.

If you want to estimate the entire process, no, forget it. There will be too many unknowns or changes or oversights to throw your nice MS Project Gantt Chart right off. Take a look at a development manager some time, see how often they spend updating their work schedules etc. They sure as hell don't do it for the fun of it.

Spam alert! (2)

wiredog (43288) | more than 13 years ago | (#2522366)

This article is also at K5 [kuro5hin.org] . In fact, it's the same article. If you want to get comments from two different places, then please post the article at one place, and post a link to it at other places.

Be afraid of the unknown (2)

blang (450736) | more than 13 years ago | (#2522370)

When making estimates, people tend to sweep under the carpet, or simplify the things they don't know, but can be quite accurate estimate the things they've built before. That's why really large project fail so badly, because every single person involved im the project has many more unknowns than known things to deal with.

So, never say "How hard can that be?" before having coded up a small working prototype.

Type of project (1)

ishark (245915) | more than 13 years ago | (#2522375)

I think that the problem is that "it depends on what you're doing". If you're re-applying for the 100th time the same metodology (= solving the same problem again, with different sugar) or if you're just gluing together pre-cooked solutions, then the process is much like an industrial project. You can make estimates, and only the normal delays will pop up.

On the opposite, if the developement is more like "research", i.e. doing something completely new, designing new solutions to known problems, extending known solution to new problems, then you're in the same boat as the scientists.
There's no way to give a correct estimate, since you don't know the exact procedure which will be followed. And no, "design - code - test" is a bit weak of a process description to be a basis for an estimation.....

Re:Type of project (2)

KyleCordes (10679) | more than 13 years ago | (#2522489)

This is the key insight, and the one that the "software engineering is a science, you hackers should go away" crowd ignores. There is no one answer to how well software development can be planned / estimated, it depends *enormously* on the kind of project.

I once has a person stand up and tell me that his organization could estimate sizable projects with great accuracy. After some questions, it turned at that the projects were essentially the same thing again and again. Duh.

On the other hand, I usually do a pretty good job of estimating costs and schedules, even when there are some significant unknowns. So perhaps the situation is not as had as some people are making it sound, either.

Incompleteness (3, Funny)

wetdogjp (245208) | more than 13 years ago | (#2522376)

Lewis also provides a link to this "introduction to incompleteness" (a fun subject in itself)

I started writing a paper about this topic once, but I never finished it.


Proper Knowledge (0)

sui (90348) | more than 13 years ago | (#2522383)

You can make an accurate estimation on how long it takes to create a software application by knowing your developers, what needs to be done, and how well they previously worked on projects. Sure there can be set backs, buts thats why its an estimation. It depends on what your making too of course, I don't think you can just set a specific date for something as big as a wordprocessing suite or a 3D game but for something along the line of a website, database, etc. You should be able to fairly accurately base your estimation of past work. Setting deadlines can be great motivators, giving company bonuses for meeting those deadlines are pretty nice as well. If nobody sets a deadline for you then you might never motivate yourself to finish it.

Estimates based on motivation (4, Insightful)

ciurana (2603) | more than 13 years ago | (#2522391)

My company develops turn-key systems. Sometimes we also develop custom solutions for our customers. Our customer base has increased steadily after the dotcom crash, when we switched from products to services. One of the reasons our customers like us is that we don't bill projects by the hour. We will the project on a fixed price, not to exceed, basis.

The programmers who work with us on a contract basis don't bill us by the hour either. After we have the design and we distribute tasks and prior to submitting the final estimate, we ask contractors to place a fixed bid.

We've done six major projects like this since March, and in all cases we finished within budget and on-schedule, and the systems are currently in production. They are all mission-critical systems running in either robotics environments or high-availability networks.

Our economic motivation is then to do things well and quickly in order to increase our profits. That also enables us to move on to the next project faster than slaving over some customer in order to bill the maximum hours.

As far as development techniques go, we adopted XP earlier on and it's working for us.



Re:Estimates based on motivation (3, Interesting)

KyleCordes (10679) | more than 13 years ago | (#2522507)

My firm also does some work on a fixed-cost basis, with similar good results. I also borrow many ideas from XP.

A key to fixed-cost is that it takes practice. Try it on a small scale before you commit to it on a larger scale, to avoid large-scale failure...

Re:Estimates based on motivation (1)

justanyone (308934) | more than 13 years ago | (#2522542)

>> We adopted XP earlier on and it's working for us

We've got to figure that the XP is "Extreme Progrmaming" as in the book by the same name (at This amazon.com link here. [amazon.com]

Team programming, like code review paradigms of the past, increase effectiveness of programming, but do require significant personnell and management input. People working together closely calls for matching personalities and resolving tech approach disputes cordially and effectively. This means adding good technical management to the team. Management is supposedly a science, but like p-sychology there are hard areas and (throat-clearing noise)really SOFT science areas that defy characterization.

Much more like manufacturing than physics. Mostly (3, Informative)

ers81239 (94163) | more than 13 years ago | (#2522392)

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.

There are four parameters (3, Insightful)

dybdahl (80720) | more than 13 years ago | (#2522395)

There are four parameters to a software project:

- Quality
- Quantity
- Deadline
- Costs

In a competitive environment with humans involved, up to three can be specified. Not four. Good examples are:

- Many guidelines for managing software projects tell you to reduce quantity when you get near deadline.
- Some customers have a specified budget but really don't know how much software they can get for that money. They prefer to have costs fixed than to have quantity or deadline fixed.
- Sometimes deadline is so important, that costs may 10-double in order to reach that deadline, and quality and quantity may get reduced a lot in order to finish the project.

It is extremely important to realize the meaning of all four parameters before you can talk about estimating project schedules.


Re:There are four parameters (1)

cjhuitt (466651) | more than 13 years ago | (#2522563)

This reminds me of a signature a guy used at a company I used to work for. (The company won't be mentioned, but let's just say there are jokes out about the returns on their stock compared to collecting the deposit on beer bottles.)

Anyway, the signature:

You can have it: Correct, Cheap, Now. Pick any two.

More like Research and Development... (1)

quadcitytj (320706) | more than 13 years ago | (#2522399)

I think software engineering is more like research and development than hardware engineering. You know what your ultimate goal is, and you can SOMETIMES estimate how long it will take, but usually, you're doing something that you've never done before. So, for large scale projects, it's VERY difficult to estimate with any degree of accuracy how long a software project is going to take.

This is why code re-use is so great. It makes software engineering more like hardware engineering, allowing more of a construction method of building software than a research "how-am-I-going-to-do-this" method.

Analysis, Design, and Project Management (2)

weez75 (34298) | more than 13 years ago | (#2522402)

There are tons of tools and techniques to developing software. Best practices abound in fact. Two things present in every form of good software development are analysis/design and project management. If you do the work in analysis and design you will be capable of building a good estimate.

That's only half the battle. Once a project is underway, keeping scope in check is critical so you need good project management. If you build a great estimate through analysis and design and then throw it out the window when you start writing code, you'll never have a good estimate.

Where do major providers like Microsoft and even Mozilla go wrong? Simple, they either jump in and start coding before they've completely settled on what they're building or they change their mind in development about what they're building. Either way, it screws up delivery dates.

Neither (0)

Anonymous Coward | more than 13 years ago | (#2522403)

Programming isn't a mechanical process (attach part A to part B) or a mathematical process (debugging = 3 days), it's a creative process that relies on a human mind to construct.

That process can be estimated, but I haven't seen an instance of setting hard and fast scheduling rules that has been successful in the long run, unless they had a whole bunch of padding in them to begin with.

The short answer: no (3, Insightful)

Tassach (137772) | more than 13 years ago | (#2522406)

I've been developing software professionally for about 14 years now. In that time, I've almost NEVER seen a development project get completed in the allotted time. This has been true even when the schedule has been padded outrageously to account for slippage.

The biggest problem I've seen is requirements creep. Most often, you don't have a firm set of requirements to start with. Management and programmers both have a tendancy to view requirements documents and other formal software engineering practices as superflourous. The problem is that without a firm set of fixed requirements, you are always trying to hit a moving target.

Another problem is attitude, mostly on the part of management, but programmers are guilty too. One faulty attitude is that we are conditioned to expect immediate results. There's also a prevaling attitude that there is never enough time to do it right, but there's always enough time to do it over. This leads to undocumented, unmaintainable masses of code that either gets thrown away after a while.

Even worse, you wind up with garbage code that SHOULD be thrown away and re-written from scratch, but winds up getting patched and modified for years. I can't tell you how many times I've had a manager say "there isn't time to rewrite it, just patch it". That would be OK if you are only going to patch it once -- but you wind up patching the same program a half dozen times, and it winds up taking twice as long to do all the as it would have if you had just rewritten it from scratch.

Not Voodoo Dammit!! (1)

deKernel (65640) | more than 13 years ago | (#2522410)

Okay, I finally found an article that I feel the need to reply too.
Writing good code is art-work, but it is not a black-art. If you spend some time upfront to design the system, you should be able to give a good estimate. Don't give me that "but its new technology" bullshit either. Then in your schedule you put a prototyping period in where all you do is write scrapable code (did you happen to catch the word "schedule" in that sentence).

That being said, Yes, I realize that sometimes manangement doesn't/won't give you that time upfront for which you will pay 10-fold in a piss-pour design. I might not be the sharpest knife in the ol drawer, but even I know that.

Basically, the moral of this rant is, just apply good engineering principles and you should be able to create a schedule (ah there is that word again) that you should be able to track reasonably close.

Extreme Programming addresses this (1)

HisMother (413313) | more than 13 years ago | (#2522412)

The Extreme Programming methodology has a way of dealing with this: basically, you only make predictions a few weeks in advance. You break everything down into individual tasks that are small enough to estimate reliably in "ideal programmer days." An ideal programmer day is a day where a programmer gets to work all day without interruption. Everyone naturally estimates this way already and people are actually pretty good at doing it. The problem is that you don't get ideal days; you get real days, where you have to go to meetings, and answer the phone, and people get sick, etc. What you do is you measure the ratio between ideal days and real days. Then you estimate in real days, and multiply by this velocity to get a reliable estimate. You can develop very reliable velocity measures for a given team in a given environment. You can update the measurement over time.

Then every three weeks, you pick enough individually estimated tasks such that the total number of ideal programmer days multiplied by a previously measured velocity equals three weeks. You then say with very good confidence that in three weeks, you'll have finished those tasks. You're virtually always right, once you've got some practice and measurements behind you. If you don't hit the target exactly, you adjust the velocity for the next iteration.

Beyond that, though, any estimates you make are understood to be back-of-the-envelope and not to be trusted. You don't bet the farm on anything you don't really know. And the customers are very happy when you hit the target time after time!

Re:Extreme Programming addresses this (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2522426)

The Extreme Programming methodology

Methodology? Sounds almost like mythology...

Strongly agree (2)

peter303 (12292) | more than 13 years ago | (#2522525)

Works very well.
You have a shippable system every 2-4 week cycle.
Each new cycle nets more features.

There are reasonable ways to get a good estimate (1)

north.coaster (136450) | more than 13 years ago | (#2522423)

I have worked in a couple organizations where schedule estimates are pretty accurate. The key, for these orgs at least, was to follow a structured development model where the requiremenst were well defined in advance. We used the Capability Maturity Model [cmu.edu] . This methology probably wouldn't work for very small or very large projects, but it works very well for medium sized project.

It's important to note that this methology is independent of programming language, operating system, etc. What is does require, however, is experience. In other words, the longer that you follow the CMM, the better your schedule estimates will be. Also not that everybody related to the progect (System Engineering, Managament, etc.) has to participate. Management in particular has to understand that it is better to have an accurate schedule that ends later than desired than it is to have a schedule that meets the desired end date but that is impossible to meet.

The amazing thing about the CMM is that the higher the rating of the organization, the less stress that the programmers feel when they are doing their work. For me, that makes it all worthwhile.


Re:There are reasonable ways to get a good estimat (0)

Anonymous Coward | more than 13 years ago | (#2522543)

The amazing thing about the CMM is that the higher the rating of the organization, the less stress that the programmers feel when they are doing their work.

Well it's nice to see that there's at least some benefit to the CMM. Several empirical studies have to date found little evidence that an organisation at level n+1 produces products which are any better than one at level n. The reason why these things don't work too well is that they assume that producing software is like cranking out cars. Perfect the process and you produce consistent-quality cars each time. The problem is that software is produced by cloning the result of a one-off product of the programmers' creativity, so methodologies like CMM and related process-based techniques are doomed to failure (or at least lack of success) because software engineering isn't like any other type of engineering process.

True Estimates are Rarely Used, Anyway. (1)

Chibi (232518) | more than 13 years ago | (#2522437)

With a few notable exceptions (companies where the developers drive everything - like id, Valve, etc), most deadlines are determined by business people who don't understand all of the business and technology requirements. Then, the development staff are forced to create a schedule that fits into this deadline. That's why you get horror stories of people working 70+ hours a week. Some of this overtime can be attributed to dedication and interest in the work, but more of it can be attributed to people feeling they have to work that much to meet the deadline.

And when the deadline is in jeopardy, most companies will try to cut corners, rather than address the real issue - lack of time. Most deadline changes come much too late.

Some Estimations can be made (1)

justanyone (308934) | more than 13 years ago | (#2522439)

I find after 10+ years C/Perl consulting:
  • I'm almost never off by more than 50%;
  • I'm somewhat more accurate when I'm the architect as well as developer;
  • Systems complexity determines uncertainty;
  • GOOD project management (not me - someone to run interference for me w/ management) can increase my effective productivity by 30-50% by assigning achievable tasks with adequate testing time;
  • BAD project management can cut my effectiveness to nearly zip likewise;
  • If I have free reign to do simplification / moderate rearchitecture as part of improvements, my effectiveness goes up again - I can solve underlying problems of bad code sections before they turn into TIME-CONSUMING BUGS.

All this adds up to good experience and a good corporate culture. Writing SIMPLE code that morons could debug (and whoever comes after you might just be one) saves tons of time and effort over the life of the code.

Book recommendation: "Enough Rope to Shoot Yourself in the Foot" by Holub has great stuff about simplifying code and reducing uncertainty in software project time estimations.

Time Estimate Uncertainty == Complexity / (ProgrammerCompetence * GoodManagement)

What a cop-out! (0)

Anonymous Coward | more than 13 years ago | (#2522441)

It's the same old generic method for disproving something. Reduce it to a formula, and then apply the Theorem of Incompleteness to it. That's the one that demonstrates the fact that no mathematical system can ever fully describe every situation. It doesn't prove that estimates are not workable, but rather that they can never be absolutely perfect.

SW Schedules (2)

rlp (11898) | more than 13 years ago | (#2522442)

SW development is still more of an art than a science. That said, I've seen several fairly common causes for late software:

1) Lack of up front planning - too many projects fail to do proper initial planning - specifically defining the problem to be solved, producing detailed product requirements, and a detailed project plan (and then sticking to it).

2) Late (or incomplete) requirements - if you went to an architect half way through home construction and wanted to change the design of a house; you wouldn't be surprised if it fell behind schedule and went over cost.

3) Poor risk management - failure to track dependencies, too many high risk dependencies ("we'll build it on the next OS release, with the new compiler, and that SW package that our start-up partner will finish next month"), failure to make and execute contingency plans.

4) Failure to heed Brook's Law ("Adding software developers to a late project - makes it later.")

5) Failure to have read Deming ("You cannot test quality into a product").

6) General design failures - not assuring that product is scalable, reliable, testable, etc.

7) Failure to place a senior developer on the team that knows about the previous issues.

Re:SW Schedules (1)

jpbelang (79439) | more than 13 years ago | (#2522570)

1) Lack of up front planning - too many projects fail to do proper initial planning - specifically defining the problem to be solved, producing detailed product requirements, and a detailed project plan (and then sticking to it).

My opinion is that long term planning fails all the time because of ...

2) Late (or incomplete) requirements - if you went to an architect half way through home construction and wanted to change the design of a house; you wouldn't be surprised if it fell behind schedule and went over cost.

...this. Customers (the people who pay) change their minds. Sales (your own) tend to over promise or even forget features promised.

I also think that getting precise requirements
is so difficult that it tends to be useless (except in a couple of businesses). Keep them simple...

My preferred developpement method is XP because it does just this.

5) Failure to have read Deming ("You cannot test quality into a product").

Which doesn't mean that you shouldn't test :)

7) Failure to place a senior developer on the team that knows about the previous issues.

Or, at least, a very knowlegable available customer.

Doesn't work for anything non-trivial (2)

renehollan (138013) | more than 13 years ago | (#2522448)

I've seen, and been subjected to software-estimation techniques.

The best defense I've heard is that "Yes, everyone's estimate will be way off, but they are independent estimates of different pieces of code and when aggregated the standard deviation drops to a reasonable value". IOW, the estimate I pulled out of my butt will be way optimistic, but your estimate will be pessimistic, and it will all cancel out.

There are a few problems with this, rather nice and neat statistical trick:

1) As Michael Milken found out, the observations are not independent -- there are two many interactions between the components being estimated. In Milken's case, he argued that a diversified portfolio or junk bonds would have high yield, low risk charactersitics. Unfortunately, the performance of shaky companies in a market downturn is rather strongly corelated.

2) You need something objective to estimate. In our case, we measured the number of easy, medium, and hard member functions of classes that had to be implemented. See the problem? You need to cast your interfaces in stone, external, and internal ones, right at the start. On simple projects this is easy, but not on hard ones, as much as we all agree it is desirable. There is something called learning from one's mistakes and it will happen with anything novel.

3) This presumes that the design is sound. To ensure this we reviewed and analyzed and studied, and "damnit, you indented 3 spaces instead of 4...", well you get the idea. The closest scrutiny will find the obvious bugs, but not the really tricky ones.

4) This technique does not encourage the one thing that saves you in the face of change -- adaptive and modular design. You make things modular so change affects as little as possible, and you make things adaptive so change is as painless as possible. IOW, you plan for making changes bacause of mistakes. Naturally, this violates (1) above, so it is not permitted. The mantra is "Design it right the first time!" We know that we can get 95% or 99% or maybe even 99.5% of it right, but never 100%.

In the end, sure, we "finished" on time, but, er what was finished didn't work very well, and had to be rescued by the few who knew what was going on. To be fair, the design efforts and documentation helped provide a somewhat modular system, but the really important parts weren't documented -- we had reams of paper describing the "trees", but not nearly enough describing the "forest" as it were.

So, I'm skeptical.

I've heard that these techniques encourage "discipline" and help mediocre programmers contribute acceptable code. Well, where I work now, we have a policy of not hiring "mediocre" programmers. I can dump a suspicious log on someone and be assured that they WILL fix the problem -- I don't have to argue that there IS a problem ("but, the process, the process says this WON'T happen... your log must be a lie...")

It's all a bunch of bull.. (2, Insightful)

sid_vicious (157798) | more than 13 years ago | (#2522461)

I remember being in my software engineering class in college the day the professor was lecturing on "CoCoMo" (think it stood for "Cost Completion Model").

He very carefully laid out the algorithm - I don't have my textbook handy, but it involved elementary mathematical operations on estimated man hours, estimated lines of code, estimated overhead, etc., then at the end -- and I am not making this up -- they multiply the result by a "magic number".

Where did you get the magic number, oh sage of the ivory tower? Well, we just made it up -- it seems to work.

It hit me then that the whole discipline of estimating cost completion is all bullshit. You might as well be estimating with a crystal ball or divining the future with chicken bones. Since I've been working, the best advice I've gotten so far has been "take how long you think it'll take and double it".

second that opinion (2)

ragnar (3268) | more than 13 years ago | (#2522575)

I agree entirely. My software engineering class involved an overview of various estimated tools and it was all BS. The systems used lines of code as a metric. What a joke. I remember the magic number, which is just a way of them reverse engineering on historical data. The bean counters are desperate for a way to understand programmers without knowing a line of code.

Our formulas (2)

scott1853 (194884) | more than 13 years ago | (#2522466)

Where I work, we just take any estimate and multiply it by 3 and that seems to be a lot closer to the end result.

Of course that doesn't stop the managers from asking every day, starting on the first day, whether or not the 3 month project you're working on is complete.

Timescale estimates are an art in themselves... (1)

shic (309152) | more than 13 years ago | (#2522479)

In my experience, the ability to give an estimate as to a timescale is extremely useful when it comes to planning. When a knowledgeable person asks how long a problem will take, I'm taken to one of these options:

  1. I've no-idea - it will take X days to 'nail down' what we want before I can give a more accurate answer... and this assumes everyone else can answer my non-technical questions immediately.
  2. This is going to be hard... Think in terms of several months/weeks or more for a first version, which probably won't be all that you're looking for.
  3. This is not really hard - just tedious - it requires X lines of code to be (trivially) altered which will probably take about X hours.
  4. This is easy - come back in a few hours - it will be ready then.
  5. I know less about this that Mr/Ms Y - so I suggest you ask them.

I have found I've got better at my estimates as I become more experienced... I've also learned that using terminology like "a few ..." is very useful, as it leaves a reasonable margin for error. It feels honest too:-) In many situations these rough guesses are just what is needed in order to start strategic plans. Even wildly inaccurate estimates are useful when you need to prioritise the order in which tasks are tackled.

I've done it (2)

roman_mir (125474) | more than 13 years ago | (#2522495)

I've being working on large mostly web based applications for the past five years. There are always problems with timelines for software design and development, but I must say that most of the problems I've seing are not actually related to computer science. Whenever the task of time allocation is done by a marketing person, the times are wrong. When I get into the room with a couple of other developers, look at the problem that is set for us from the very beginning, from basically the reasons why this application is developped and who the users are to the point where we have to understand the datamodel, the time assignment exercise becomes much more clear. For a person with experience, it should be possible to estimate time for a task if this task resembles some of the person's experiences in the past. Of-course everything new has new risks associated with it, that is why you must always allow some slack for every specific task within the entire project. It also helps if you know who your developers are and if you have seeing these people at work before.

Yes, it can be estimated (1)

TheBracket (307388) | more than 13 years ago | (#2522498)

As the subject line, software development time can be estimated throughout the lifecycle of a project. Estimates don't become realistic until you've mapped out the exact framework of which code will do what, and planned every single discrete module (as in extreme programming, every module should be distinct and testable). Once you have this - and have a map showing dependencies - its not that hard to figure out how long it will take to create. Add in some flexibility (because humans are fallible; even the best programmers in the world have bad days, get the flu, break up with a girlfriend, etc.), and you have a realistic estimate. Its worth adding to the "programming time" estimates for every module to ensure time for thorough testing (insist on testing at all levels), as well as a detailed beta stage and rollout phase. Depending upon the complexity of the project, these can be large phases.

On the other hand, a poorly-planned, creeping-feature project with little engineering and a lot of hacking/coding probably is impossible to predict with any degree of accuracy.

Defining Requirements (1)

Snar Bloot (324250) | more than 13 years ago | (#2522500)

It's the time getting the exact requirements nailed down that's toughest to estimate, that's where you need to get all the "creep" out of the scope.

Then, if that was properly done, the rest of the construction should go on schedule.

And don't accept unrealistic timeframe requests...

Laff: Of course it can be estimated (1)

dbretton (242493) | more than 13 years ago | (#2522502)

Accurately, too!

I would dare to say that the first iteration will fall within about a 2 sigma error margin. That is, your first estimate on your first major program will have a bit of variance in it.
It is a matter of obtaining the correct measurements of performance, time, and complexity for the project.
After the first iteration, accurate estimations can be performed rather easily.
No secret at all, really. Good metrics, a clear understanding of the problem space, and strong control (i.e. exacting configuration management) lead to a successful, well run program.

Quick example:

My customer wants me to design a fault tolerant, web-based acquisitions program to manage a 5,000 employee company's transactions. All of this is via an intranet. (the problem really doesn't matter. I just thought I would toss it in to give "details" people something to think about)

1. Determine problem statement/space.
Get the details! Determine the business-level requests. Brainstorm and develop a document listing the details (implications) of the problem.
Present to the customer. Iterate until problem is completely defined.

2. Draw on previous experience to determine approximate complexity of code. This can be tough, as complexity can be hard to factor. Look at the interactions, locations of system fault, probability of fault, and cross-cutting concerns in system usage.

3. Leverage step 2 with previous metrics, such as source lines of code (SLOC), to make a first order estimation on total code to be produced.

4. Combine SLOC estimate with pre-recorded employee productivity (SLOC/{week,month} as well as error rates (#bugs/{1k,10k}SLOC), to determine the length of time to produce the working product. Note that the above metrics usually include test, demonstration, verification and validation time.
Factor in SLOC conversion rates if the application language differs from the baseline. (e.g. C->Java 1.3, JAVA->C++, ~1.0, Ada->C++ 1.2, cobol->C,...etc)

5. Determine the migration time, if applicable, to move the customer's current base to the new product.

6. Determine amount of time to distribute and train the customer for the new product.

7. Roll numbers in, mix, and viola: you have your numbers for development of a project.

Note that none of the above mentions product life cycle support and the like.

IEEE J-STD-016-1995 is a good source for software life cycle process.


Incentive is to Underestimate (1)

dilute (74234) | more than 13 years ago | (#2522512)

Any estimate of development time is a prediction of the future, and thus always subject to the impact of unforeseen events.

Nevertheless, it is possible to estimate many aspects of development, especially if there is a track record of similar jobs.

But . . . it seems to be in the interest of the developer, most of the time, to underestimate development time and cost. That way, you get the work. Too long or high estimates (even if honest) scare people away. Once the commitment is made to a lowball estimate, and time and money sunk, the organization doing the commissioning is to some extent over the barrel, and will have no choice but to accept some (sometimes substantial) delays and overruns.
The moral, I think, is don't rely on an estimate given by the people who are going to do the development.

I'ts not impossible, but... (0)

Anonymous Coward | more than 13 years ago | (#2522530)

...you need a lot of experience and a lot of delayed projects on your shoulders. I think about the project, make some blocks, an idea of how it should work, then I say "Uhmmm... that's 1 month". Here i don't use de 2x or 3x. I take that number for the mean delay of the previous projects. I call that number the "Engineers Optimisic Index" (Or pessimistic, i alweys underestimate the times). Thet there are a crucial factor that is the part of the year the project must be done. In summer I add a factor of 1.5, in winter 1, an some number between in fall and spring depending of how i see my workers.
I have a more controlled delay, but the problem is that most of my customers doesn't accept the prize rise. No problem, at last I know how munch it will be delayed, and I have a lot of time to prepare two or more excuses.

Try common sense (2)

joss (1346) | more than 13 years ago | (#2522536)

WRT software schedules - seldom has so much crap been written by so many for the benefit of so few.

The problem is that the term "software schedule" is too wide a field to say anything meaningful about it. If you want to estimate how long it will take to put together a customized ecommerce web site, and the organisation has already built 5 of them, there is no problem. If you want to solve some problem that hasn't been solved before, it could take a week or a hundred years. Recognising the difference between these two cases is less simple than one might expect. And, if there's genuinely no novelty in the problem one should not be writing software at all. Someone should just write an application to solve that general class of problems.

People get unstuck when they break the problem down into small chunks and then guess a number on each chunk. Often the initial decomposition misses crucial interactions and needs to be refactored later on. This is a bit like answering the problem about how long is a piece of string, by saying - well the string eginning, a middle and an end, I estimate each piece is 5 inches long, so the string is probably about 15 inches long. Unless the breakdown has brought genuine insight into the unknown aspects of the project, the estimate it provides is worse than useless. However, since one can then stick things out in MS project, print out pretty GANT charts, etc, this estimate is given more credence than a number generated by just reading the spec and making an educated guess.

Part of the problem is that it's described as software engineering. Then we get all sorts of morons saying: civil engineers can tell us how long it will take to build a bridge, the problem must be that software engineers are unprofessional or that the subject is in it's infancy - things will improve. No, they won't, for the same reason that mathematicians couldn't tell you how long it would take to solve Fermat's last theorem.

ScheduleTime = EstimatedTime * Math.PI (0)

Anonymous Coward | more than 13 years ago | (#2522537)

Works well for me.

Provably impossible (1)

QuickFox (311231) | more than 13 years ago | (#2522539)

A mathematically rigorous examination will show that predicting development time is impossible since it's impossible to predict how interesting Slashdot will be and how much time will be spent there.

Some parts of the process are schedulable (1)

CodeWheeney (314094) | more than 13 years ago | (#2522552)

I'm a developer with about 8 years of professional experience. I can say that, in those 8 years I've been involved in 4 or 5 BIG projects. Of those, one was estimated accurately. It happened one stormy night .....

We (the engineering team) did not give an estimate for code completion until after a significant amount of design was complete, and we knew where the high risk areas of the project were (FYI, this was a major revision to a shipping product, 1.0 to 2.0 kind of thing).

We broke down the work to be done into as many discreet tasks as possible, and found all the risky and dependant tasks and carefully reviewed each one, including proof of concept coding (which we got management approval to throw away).

We then estimated the development tasks (including more detailed subsystem design and all development tasks, along with testing and documentation). These estimates were done by the developer(s)/testee(s)/doc folks who would be doing the work.

We then aggressively kept track of our progress, and attacked any slippage immediately. We had testing in place from the first month (including nightly build and smoke tests, etc). We did not have many meetings for meetings sake, but everyone had ownership in the schedule, everyone re-factored as needed (ala XP), everyone concentrated on beating down risk, and we had a team that worked well together.

All in all, I think this 12 month project was successful for several reasons: 1) We treated it as a very complex thing, which it was. 2) We attacked risk immediately. 3) We kept an eye on the schedule, and 4) We got lucky. 5) Marketing requirement changes were few, and the schedule impact was examined before acceptance/rejection.

Luck is not to be discounted. We managed to identify all of the really risky parts and not get surprised by any odd things (considering we were writing for new technology).

Overall, I'd say that parts of the software process can be estimated accurately. It is important to distinguish design from development work. That is, don't try to schedule the wandering, brain draining, R&D-esque part of development, it's too spasmodic. But, make sure to give it enough time, because if the design bits leak over, you're in trouble. And, this will happen, so spot it and account for it immediately.

No such thing as Software Engineering (1)

Whip-hero (308110) | more than 13 years ago | (#2522558)

This is a subject that really irks me in light of the conventional "Software Engineering" mindset. Most of SE nowadays seems to be aimed at making software projects as predictable as possible, as if they were like civil construction projects. The fact of the matter is that they are not like building projects... If we conform to the doctrine of software re-use, on of SE's central tenants, we should never have to re-write a piece of software, so we will never know what the complexity of the related problems are until the project is finished. Software has nothing to do with engineering- it is more like original composition, like writing a symphony or novel, except that it also has a constraint for rigorous correctness. Physics is a good analogy for that.

It's a question of money (1)

jdoeii (468503) | more than 13 years ago | (#2522562)

With proper planning the duration of a software project can be estimated with very high defree of accuracy. The problem is that proper planning itself may take as long as 50% of total project time.

In case of manufacturing, the process is known. Proper planning was done in advance, when the manufacturing process was developed.

In case of physics one has to solve the problem before he would know how complex it is. Proper planning is the process.

Basically, stick to projects you understand and planning should be a piece of cake.

The magic eight ball (1)

SilLumTao (134743) | more than 13 years ago | (#2522567)

I keep a magic eight ball at my desk for project estimation.

BOSS: We need an wiz-bang feature added for customer XYZ, pronto! Give me an estimate.
ME: Oh, magic eight ball, can this feature be completed in 6 months?
8-BALL: The future looks cloudy.
ME: Oh, magic eight ball, do we assign more than 5 people to this project?
8-BALL: It seems likely.
ME: Oh, magic eight ball, will I get a bonus if the project is done on time?
8-BALL: No freakin' way.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?