Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Can software schedules be estimated?

By noisebrain in Technology
Tue Nov 06, 2001 at 12:16:32 AM EST
Tags: Software (all tags)
Software

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?

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.


An introduction to mathematical incompleteness (a fun subject in itself) and other background material for the paper is here.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Large Limits to Software Estimation
o here
o Also by noisebrain


Display: Sort:
Can software schedules be estimated? | 35 comments (28 topical, 7 editorial, 0 hidden)
Practical observations (3.62 / 8) (#4)
by frabcus on Sun Nov 04, 2001 at 08:31:22 PM EST

My take on software schedule estimating (having just had to do some last week):
  • If you don't guess timescales, you give yourself / the team an excuse to slack, or do unimportant things, or do important things too well.
  • Time estimates are always going to be wrong. If you have a base, you can at least tell it is wrong, and start cutting back features, changing staffing, reducing quality, or increasing the timescale.
  • It's fun! Makes a change from programming. You can just make up numbers, and nobody expects them to be right, or can prove that they're wrong. Very refreshing.


Vindicated at last! (4.89 / 19) (#5)
by Mr.Surly on Sun Nov 04, 2001 at 11:26:41 PM EST

It's so frustrating it is for me and my boss when it comes to largish projects:

(Dave is my co-worker)

Boss: "How long will feature / subsystem X take?"

Me: "6 to 8 weeks" (a long time)

Boss: "No, really."

Me: "Really, I don't know. Estimating the amount of time programming will take for anything but a trivial program is a non-linear ..."

Boss (now pissed): "Spare me. You've told me that a thousand times. How long will it take?"

Me: "Just tell the client 6 weeks. Hopefully it will be less."

Dave: "A week. A 2 weeks tops."

Me: < Looking annoyed at co-worker >

Boss (happy): "Good!"

~~(one weeks later)~~

Boss: "Why aren't you done with X yet? You said it would be done in a week." (Bosses always hear the shortest time estimate)

Me: "I didn't say that, Dave did. And he said it could take up to 2 weeks." (Yes, I really do have to memorize every conversation because of this)

Boss: "Well, the customer is upset. I told him it would only be a few days, and it's not done yet."

Me: "You shouldn't have done that. These things are hard to predict."

Boss: "You know, we have deadlines to meet around here so we can get paid. The those deadlines have been there for a month. This is no surpise."

Me: "You pick arbitrary deadlines, that we might be able to make, except you throw 3 or 4 other projects on us, then schedule all of them to be delivered to the customers at the same time."

Boss: "But you knew when the deadline was. How could you miss it?"

Me: "Just because I know when the deadline is doesn't mean there's enough time to make the deadline, especially when more work is thrown at me in the interim. Besides, this project had a spec that was scribbled on a napkin in 5 minutes, and has a severe case of feature-creep."

-------------------------

It usually goes downhill from there.

*sigh* I guess I should be happy to have a development job these days.

Hey! (none / 0) (#22)
by finial on Tue Nov 06, 2001 at 11:12:54 AM EST

Hey, I remember that conversation. But my name's not Dave.

[ Parent ]
oh my! (none / 0) (#29)
by Sairon on Wed Nov 07, 2001 at 07:12:08 PM EST

I think you have my old job! Tell Dave he's not getting his coffee cup back and yes I think it's weird to not eat meat... on a serious note, if all developement jobs are just like the one I had, I think I'll stay where I am... construction. At least we know when we should be done and can tell who's at fault if we don't make it on time.

Jared

[ Parent ]

Revolutions drive people in circles (3.40 / 5) (#6)
by slaytanic killer on Mon Nov 05, 2001 at 12:09:26 AM EST

That is something to keep in mind. Not only do we sometimes have a difficult time finding the execution properties of the algorithms we use, but we are to also find the execution properties of those humans who have to figure out the execution properties of the algorithms?

Architects and McDonald's managers can determine a fair amount of time for making burgers and buildings. Except when making something new and experimental. Then budgets and schedules go out the window.

Programming tools and libraries have to progress to the point where the coding we do is dull and mindless. Before then, the wheel will be reinvented quite often.

Rapid Development (4.00 / 6) (#7)
by jabber on Mon Nov 05, 2001 at 04:12:52 AM EST

Look up the book Rapid Development. It gives a good overview, as well as plenty of practical hints, on various development processes, timeframe estimation, risk mitigation, software lifestyle and all sort of other goodies.

RD shows that some projects can in fact be estimated, while others can be reasonably guesstimated, while others still are black holes, death-marches and the like.

While reading, do NOT neglect The Mythical Man-Month. It's the closest thing to a silver bullet there is.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

Does not hold water (4.00 / 2) (#11)
by forgotten gentleman on Mon Nov 05, 2001 at 09:53:12 AM EST

I am going to write a long post, and I hope it will make sense to everyone. I think this paper is a very good way to approaching the problem. But looking closely at the paper, it does not show that programming is more like physics than manufacturing.

The structure of the paper is to show that program complexity can not usefully be computed beforehand, and then argue from there that productivity can therefore not be computed.

However, these arguments can be applied to manufacturing. If you have a company that can produce anything, then you can not fix a bound on productivity either. If you apply the phrase "program size and complexity" by saying that a program is a finite, understood process to convert raw material to finished goods, then the claims should apply to manufacturing.

What does manufacturing do that is so different from physics? Well, manufacturing limits itself to a subset of production where productivity can be bounded. "Process size and complexity" are bounded. If it isn't, then it's handcrafted.

And for programming, that means there are areas where program size and complexity is bounded. If you can develop for one platform, using a sufficient library, then you are closer to manufacturing. That is why experienced people can become good at estimating, and why companies must retain these people at nearly all costs.


My favorite comparison (4.50 / 4) (#13)
by rusty on Mon Nov 05, 2001 at 10:58:17 AM EST

My favorite comparison to estimating the time it takes to finish a software project:

"You have lost your keys. How long will it take you to find them?"

Stolen from an unremembered source. "The Mythical Man-Month" perhaps?

____
Not the real rusty

Yes, it can. (4.25 / 8) (#14)
by ucblockhead on Mon Nov 05, 2001 at 11:42:11 AM EST

And I have done it.

I frankly do not understand the linked article in any deep way, but I don't put much credence in it as it seems to make two mistakes. One, that estimation must be "objective" (it is largely subjective), two, that we are looking for exact answers, not estimates. To me, this seems like saying that we can't fly spaceships because there's no exact solution to a three-body system.

Anyway, I've brought multi-person projects in on time. I didn't use any particular methodology, just followed some loose rules:

  • An estimate is only as good as the specification, and no specification is perfect. Constantly work to improve the spec, even as the project is going forward, and revise the estimates constantantly in accordance.
  • Keep metrics on how fast people are completing assigned pieces, and use that to continually re-estimate the rest of the project, and to decide who to give which piece as earlier pieces are completed. (You don't need a fancy tool for this. I used Excel.)
  • Talk to the people that the project is for, and tell them the minute it looks like the project may slip the deadline. Offer them alternatives to fix the problem, either extending the deadline, dropping features or getting new people. Make it clear that re-estimating and hoping for a better answer is not an alternative.
This is a royal pain in the ass, as it often entails being a badgering asshole, often to your superiors. But it works. Estimation, subjective estimation, is critical to it.

Most projects miss deadlines not for any bizarre, unknowable reason, but for very simple, easy-to-predict reasons. The specification is crap. The project manager is afraid to approach his boss when the date starts to slip. The project manager isn't tracking how well his estimates are. The estimate is based on when they want it, not on when the people who know the technology think it can be done. Things like that. It ain't rocket science.
-----------------------
This is k5. We're all tools - duxup

second this (4.00 / 1) (#15)
by speek on Mon Nov 05, 2001 at 01:07:21 PM EST

You said it perfectly. The idea of going to Godel to prove that software can't be estimated is ludicrous. Stop trying to prove what's mathematically possible and start working out solutions to your problems. You need common sense, not advanced mathematics.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Thats the point (none / 0) (#34)
by Paul Johnson on Sat Nov 17, 2001 at 09:49:15 PM EST

it seems to make two mistakes. One, that estimation must be "objective" (it is largely subjective),

Which is the point. If estimation is subjective then it basically comes down to someone sticking their finger in the air and giving an opinion. There may be lots of process and razzle dazzle to hide this, but ultimately its just what someone thinks.

But the CMM, DOCOMO and their relatives suggest that estimation can be made objective. It may still be vulnerable to statistical fluctuations, but we can put error bars on them just as we might put error bars on the estimate for a building project based on the observed variation between bricklayers.

The point of the article is that objective estimation is a chimera, and furthermore there are significant limits to the accuracy of estimates from even subjective estimation. In essence you can only estimate the size of the project once you know how the software will work, but by that stage you have already done a significant amount of the design work required to write it.

two, that we are looking for exact answers, not estimates.

No, it does not assume that. It explores methods of estimating an "upper bound" to complexity and shows that there is no feasible algorithm to do so. If we could define an upper bound on the cost that would definitely count as an estimate.

Paul.
You are lost in a twisty maze of little standards, all different.
[ Parent ]

Hmmm... (3.25 / 4) (#16)
by mickj on Mon Nov 05, 2001 at 01:49:53 PM EST

wasn't this posted on /. already? By the time this gets accepted i'm sure there'll be enough discussion on the subject already.

I dont read slash dot. (none / 0) (#28)
by jforan on Wed Nov 07, 2001 at 03:27:18 PM EST

I don't have time to waste looking through that many articles for interesting and valuable perspectives.

So I appreciate interesting things to be posted here.

However, this probably should be under MLP
I hops to be barley workin'.
[ Parent ]
It depends on the people above me. (3.00 / 3) (#17)
by Fubar the Clown on Mon Nov 05, 2001 at 03:33:47 PM EST

If my is smart, and he usually is, he gives me a detailed written spec and leaves me alone. I take an hour to read it, and if its easy to do I call him before I leave for the day and tell him its done.

If the spec is moderately difficult, I call the boss at the end of the day and tell him that I will probably have the job done in a week.

And if the job is a hard, then my boss knows to give me at least two weeks.

Then again, there are times when my boss decides to be a schmuck. He'll tell me to implement a feature/routine/etc. with the requirements spilled off the top of his head. Even though I record these talks to tape, I always waste time reviewing the tape and trying to figure out what the boss was saying. He's a better writer than he is a speaker.

Worst of all is when somebody walks into the cubicle and says, "Are you done yet? How long will it taaaaaaake?" My answer to that question is usually, "I could have had it done already if you kept your damned mouth shut!"

BTW, this is my first job, I've held it for almost 2 years, and I get a hefty raise 4 months ago. I must be doing something right.

--
Coming soon from Megafarce Records: Antipop Superstar by Fubar the Clown

And if the job is REALLY EASY... (none / 0) (#18)
by Fubar the Clown on Mon Nov 05, 2001 at 03:35:41 PM EST

...then I call my boss in an hour and say two words: I'm bored.

--
Coming soon from Megafarce Records: Antipop Superstar by Fubar the Clown
[ Parent ]

extreme programming (4.66 / 3) (#19)
by mydigitalself on Tue Nov 06, 2001 at 09:36:55 AM EST

i'm an analyst. *waits for flame*. anyway. my previous job was taking business requirements, producing technical and functional specifications and managing the development process.

the projects were mainly large integration efforts taking financial services legacy systems online.

we would generally spend a large portion of time gathering business requirements, analysing the architecture and then documenting everything. getting sign-off took forever.

then we are 1/3 of the way into the project (say maybe a month of development has happend) and we will present our first deliverable. now often this deliverable cannot always be a skeleton of the entire project - dependancies get in the way of this. so maybe half of that code has no visible business benefit at the time of presentation (class structures, authentication services blah blah).

what i saw in that environment is that once you've shown something to the customer (and you HAVE to show them something to alleviate their paranoia) that when feature creeping begings and this is where the project is seriously threatened. normally because the customer wants more out of the software and is not prepared to compromise on time or cost. i would find this happening more often than not with just the general user interface and some process flow changes.

if would take forever to go into every detail of every dialogue box and behaviour - and ultimately the customer would change his/her mind about something.

many of our project ran over time because of this. hundreds of small, seemingly insignficant changes build up - and like a swarm of ants devour your deliverable!

my new job! we practise something called extreme programming (www.extremeprogramming.org or www.objectmentor.com) or XP - not to be confused with Microsoft XP junk.

do youselves a favour and read about it, but i'll give you the readers digest of the process:

1) iterative programming and deliverable cycles. we basically work in 2 week cycles of development. every piece of functionality (we call them stories) that is in the cycle HAS TO HAVE VISIBLE BUSINESS BENEFIT. this way the customer can always see something and if he/she changes his/her mind, the impact is quite small. for instance, we have changed our entire product architecture from a user perspective three times in the last 2 months with minimal impact to our costs or schedule! when a customer writes a story and hands it over to the developer, the developer gives an estimate. the customer MAY NOT ask for a smaller estimate. the customer therefore has to either accept the time frame or reduce the scope of the story.

2) pair programming. i don't know how applicable this would be to distributed open source environments. but this is key to XP. two programmers always work together on production code over one keyboard. you should see the dynamics in practice. coders spot each others errors quickly and utilise their strengths in a very productive means.

3) test first design. before you write a single line of code, your customer has to provide you with an acceptance test. then what you do is you write a unit test to emulate this. lets say as a customer i wanted you to write an object that added two numbers together and came up with the correct answer. you as the developer would first write a test that would take 4 and 5 and produce 9. you would then write the object and run the obejct against the test harness. basic example, but the level of quality achieved is incredible!

4) the two final and most pertinant concepts are that of rights. the customer has the right to change his/her mind at any time with regards to the functionality. and. AND. the developer has the right to change his/her mind with regards to time. important to realise is that the customer has the right to be informed of schedule change.

take point 1 and point 4 together and you will realise that you are ALWAYS aware of the status of the project. you don't get those horrid situations where you are 1 week away from launch and one of your developers comes to you and says oh i'm sorry, this i going to take another 5 weeks! you would have known this earlier and you could have either accepted the time shift and budgeted accordingly - or adjusted the scope.

there's a lot more to it than all of that. the guys at objectmentor.com have written some great books about XP if you are interested in a more in-depth look at the process.

Quick link (none / 0) (#20)
by Cameleon on Tue Nov 06, 2001 at 09:54:37 AM EST

I've always been intrigued by XP since I first heard about it. I haven't been able to try it, since I only program little hobby programs.

Anyway, here's a good introduction to Extreme Programming.

[ Parent ]

urgh! (none / 0) (#21)
by mydigitalself on Tue Nov 06, 2001 at 10:25:22 AM EST

extremeprogramming.org has crappy information architecture. if you are interested, check out amazon for:
if you are more of a manager then planning is more for you!

these guys all work at objectmentor.com who did our XP coaching and stuff.

[ Parent ]
XP and schedules (none / 0) (#25)
by SlydeRule on Wed Nov 07, 2001 at 01:34:53 AM EST

The question was not whether it was possible to be aware of the status of a software project as it progresses; the question was whether it is possible, at the outset of the project, to establish a reasonable estimate of its completion date.

Agile methodologies such as XP handle the scheduling issue by, in large part, waving it away. They are based on the notion that since the full scope of the project isn't known, the full schedule is unknowable.

The only estimates given are what features will be delivered in the current iteration, which is typically a few weeks in length. Beyond that point lies the unknown.

This is acceptable in many cases; in other cases, it is unacceptable. It depends on the project.

Martin Fowler notes, "Adaptive processes and unstable requirements imply you cannot work with the usual notion of fixed-price. Trying to fit a fixed price model to an adaptive process ends up in a very painful explosion."

[ Parent ]

Offtopic Question (none / 0) (#35)
by Simon Kinahan on Mon Nov 19, 2001 at 06:36:43 AM EST

I have to ask this: If you're an analyst in an XP environment, what exactly is your job ? One of my concerns about XP has always been the jump from a user story (or scenario) to code without any formal intervening deliverables to help cross the semantic gap.

Simon

If you disagree, post, don't moderate
[ Parent ]
You can make estimates, given enough experience (4.00 / 1) (#23)
by drhyde on Tue Nov 06, 2001 at 11:52:04 AM EST

but that's all they are, ESTIMATES. An estimate is not meant to be correct, it's meant to be a guideline. If I'm given a project that all my experience tells me will take about a month, I'll tell the boss that I think it MIGHT take two months, and I require that all such communication be backed up in writing, so that there's a record somewhere that I can point to proving that I never agreed to any insane deadlines. And I make it ABSOLUTELY clear that all change requests must be recorded, and that they *will* have an impact on the delivery date.

One thing I like to do as a developer is to be in on meetings with the client right from the start - right from the initial pitch if possible. Just having me in the room stops sales drones from promising the impossible, cos they know I'll slap them down in front of the customer. Instead, they go through things with me beforehand to make sure that they don't embarrass themselves. I also insist on being able to make comments and changes to the first draft of any spec. If all of that happens, I usually hit the deadline, which is good. I also get a reputation with the suits as being a 'customer-centred' developer, which doesn't do any harm either :-)

I'm now employed as a Project Mangler, and I try to treat the developers the way I would want to be treated. No complaints yet, and no missed deadlines.

Flame bait (4.00 / 1) (#24)
by Maniac on Tue Nov 06, 2001 at 06:37:11 PM EST

Q: Is programming like manufacturing, or like physics?
A: At several places like manufacturing. At some places like chaos theory. There is a broad spectrum in between.

C: We sometimes hear of enormous software projects that are canceled after running years behind schedule.
A: Agreed. As several books have noted, there is an order of magnitude (or more) variance in the ability of teams to produce working products.

C: 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.
A: My favorite method of estimating work and schedules is is to break down the system into a number of "things" [to distinguish from the "objects" word], get a size estimate for each, and feed the answers into an intermediate level COCOMO model. I will also give you error bounds on the estimate (+/- 3 sigma). I have also been successful at delivering within those bounds. What you do with that estimate is something else entirely.

C: With objective schedule estimates, projects should never run late.
A: Not true. Even if I said that + 3 sigma was 20 weeks, a small percentage of jobs will take longer than that. That happens in manufacturing as well.

C: Are these failed software projects not using proper software engineering, or is there a deeper problem?
A: People don't understand what the word estimate means.

Closing Comments

I read the paper referenced in the original message. I don't necessarily get through all the math, but it doesn't pass the BS detector for me. Of course, I only have to have a good enough track record with making estimates and getting the project team to deliver to keep my job....

Missing the point (none / 0) (#26)
by context2000 on Wed Nov 07, 2001 at 05:02:06 AM EST

Does COCOMO claim *objective* estimates? If so, how does it get around the need for an objective measure of project complexity.

If not, you're misunderstanding what the article is about (read the introduction and end). Actually the points you make all refer to the lead-in rather than the article.

"My favorite method of estimating work and schedules is is to break down the system into a number of "things"" does not sound very objective (my way of doing this breakdown can be different than yours). Of course you may have an adequate record of estimation, your subjective judgement is good.

Read carefully- the argument is to do with claims of objective estimates. False claims are clearly irresponsible, and since objective estimates require an objective estimate of complexity, which is not possible,...

[ Parent ]

Not quite... (none / 0) (#27)
by Maniac on Wed Nov 07, 2001 at 10:01:55 AM EST

To quote from the Foreward of Software Cost Estimation with COCOMO II
COCOMO II is an objective cost model for planning and executing software projects
So - yes it does claim "objective estimates". Depending on which particular part of the cost model, it requires as input an assessment of several factors as well as a "size estimate" (lines of code, function points).

When I used the term "things", I will generally deal with items defined at different levels of detail. For example, we may have a large item which we will use "as-is" or with minor modification. We have the actual size of that item, but it may be several thousand lines of code. We have other "things" where we do a functional decomposition or object model to determine what is required, estimate the size of each item based on similar work. In those cases, the size of each item might be less than 100 lines.

Once we have the items defined, we use the model adaptation factors to determine the effort required to use it. In all cases, we have an estimate the size of each item (with error bounds), and do the appropriate sums (of the totals and errors) to get the final size estimate (most likely, +/- sigma). That goes into the model to estimate the effort and schedule - again w/ error bounds.

With a decomposition of the system into a few items, you get crummy estimates - say +/- 150% or more for 3 sigma. But you can do that estimate in an hour or so, but even this is an objective estimate.

However, you do that with a hundred (100) items you will find that your error bounds can be less than 10% of the total effort. Far better than what most groups can do.

[ Parent ]

If you're unable to make accurate... (1.00 / 1) (#30)
by Cyber Insekt on Fri Nov 09, 2001 at 03:21:20 PM EST

...software development schedules surely that's your own personal problem, not something you should write papers about in order to justify your own failings.
--
Disclaimer: Every proposition I state should be read only as a statement of my belief. There is no guarantee that it's actually true.
Being able to estimate schedules is... (4.00 / 1) (#31)
by Cyber Insekt on Fri Nov 09, 2001 at 04:03:05 PM EST

...algorithmically equivalent to being able to write the code. Here's a proof:

First define SPEC(X,Y) to be the specification "Find the most efficient piece of C code starting with the code X that fulfils specification Y".

Then we can define TIME(Z) to be the time it takes to implement specification Z. For example TIME(SPEC("#inclu","Print out 'Hello, World!'")) is of the order of seconds.

So suppose you are given a specification X. Evaluate TIME(SPEC("a",X)), TIME(SPEC("b",X)), TIME(SPEC("c",X)), ... Go through all 256 ASCII characters, not just the alphabet. Now pick the first argument of SPEC() that gives the smallest of these values. That is now the first character of your code. Suppose, for example, the first character is '#'. Now evaluate TIME(SPEC("#a",X)), TIME(SPEC("#a",Y)), ...

I think you can all see how it goes. So having an algorithm to estimate schedules implies you have an algorithm to write code.

But that's not all! We know there is no algorithm to automatically write code (halting problem 'n' all that). Therefore there is no algorithm to estimate schedules. So this is another proof of what the article claims.

It's also just as ridiculous.
--
Disclaimer: Every proposition I state should be read only as a statement of my belief. There is no guarantee that it's actually true.

followup (none / 0) (#32)
by noisebrain on Sat Nov 10, 2001 at 09:38:38 PM EST

Yes, though the problem with SPEC(X,Y) is that it's a bit artificial, invented specifically for this argument, rather than something that the software estimation consultants would naturally invoke-whereas a SPEC(X) or TIME(X) are things they do invoke, albeit not with such labels.

> It's also just as ridiculous.

This might be silly stuff if no one believed the contrary, but there is an industry of people who claim that they do objective estimates. See the person several posts down, who writes:

"COCOMO II is an objective cost model for planning and executing software projects"

or look at the quotes gathered in the introduction to the paper.

Software estimation can be done, but it is inherently subjective (and thus requires experienced and reasonable people to do it).
But claiming that it can be done objectively is arguably not just wrong but irresponsible as well.



[ Parent ]
Comments on the posts (5.00 / 3) (#33)
by noisebrain on Sun Nov 11, 2001 at 12:01:15 AM EST

For the many people who posted responses without reading beyond the lead-in: yes the argument is in the general ballpark of "software estimation is hard or impossible", but it actually says something more specific than that.

The article does NOT say the following:

  1. software estimation is impossible
  2. objective software estimation is impossible therefore software estimation is impossible

The article DOES say

  • Various software engineering authorities claim that objective software estimation is possible [paragraph 3, quotes on first page].
  • objective software estimation is in fact not possible [body of article]

From this, it does NOT conclude either of the points 1,2 above. Instead, it concludes:

  • Software construction is inherently creative and subjective, having more in common with physics than manufacturing; software estimation is inherently subjective [conclusion, Bollinger quote].
  • Because software is used in the government, in vehicles, and other places where it can potentially have a negative on people's lives, we (software writers) have an ethical responsibility to not over-represent our ability to estimate (especially when it comes to software quality- r.e. correctness claim in the supplementary material).

Now some of the response posts, paraphrased:

  • "The article says that estimation must be objective rather than subjective"
    No, it does not say this.

  • "The article says that subjective software estimation is not useful"
    It also does not say this.

  • "The article says that we are looking for exact answers, not estimates" or "the article doesn't understand what `estimate' means"
    No, the article distinguishes subjective and objective estimates, and specifically discusses the case of an objective estimate with bounds in detail.

  • "People/organizations can make accurate estimates, I made one last week" or "Estimation is hard, I double my estimates and still miss them".
    Ok, but slightly off topic: the article is specifically talking about those who claim objective estimates.

  • "You can do objective estimation, and I did it last week using COCOMO"
    And where did you get an objective estimate of the complexity of a new project? Read the article...

  • "Software estimation needs common sense, not advanced mathematics."
    Certainly. The 'manufacturing' camp of software estimators (Humphrey quote in the supplementary material) say or hint that software construction can be made into a repeatable, fairly boring process where projects are always on time and programmers are like factory workers. This may or may not be true (I don't think it is), but regardless: to make this view seem more science than philosophy some of these people have fallen into the trap of cloaking their estimating process with formal notation and claiming or hinting objectivity. This part is wrong.

    On the contrary, [conclusions to the article and the supplementary material]:

    Good estimation therefore requires experience and judgment. The software industry should value human experience, intuition, and wisdom rather than claiming false objectivity and promoting entirely impersonal "processes".


Can software schedules be estimated? | 35 comments (28 topical, 7 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!