Free Republic
Browse · Search
General/Chat
Topics · Post Article

Skip to comments.

Software Estimation: How Misperceptions Mean We Almost Always Get It Wrong
Dr. Dobbs Journal ^ | April 08, 2014 | Carol Dekkers

Posted on 04/09/2014 5:11:04 PM PDT by ImJustAnotherOkie

Software developers are among the smartest people on the planet and often boast advanced degrees in mathematics, engineering, or computer science. In some ways, they are like superheroes — capable of programming complex functions, juggling myriad technologies, morphing customer ideas into working software, all the while not breaking a sweat. So how is it that despite such technical savvy and programming prowess, they are so woefully poor at project estimation? Study upon study cites that less than one-third of projects are delivered on time or on budget. Couple this with the fact that close to half of the effort spent doing software projects ends up being "rework" and the whole situation seems to defy logic. How can smart people produce dumb estimates?

(Excerpt) Read more at drdobbs.com ...


TOPICS:
KEYWORDS:
Navigation: use the links below to view more comments.
first 1-2021-4041-6061-66 next last
This article is so wrong on so many levels. Software developers don't make estimates, in the best case ex-software developers (ones who got bored with it or promoted using the Peter-Priniciple) did. The vast majority barely know what a Crosstab is let alone a Hash key or an OO Instance.

I've been to project meetings and they drive me nuts. People repeating what other people say,

The dead give away was in the title.

How Misperceptions Mean We Almost Always Get It Wrong

.

What is this 'We' kemosabi. Can the author explain the basic principles I stated above?

1 posted on 04/09/2014 5:11:04 PM PDT by ImJustAnotherOkie
[ Post Reply | Private Reply | View Replies]

To: ImJustAnotherOkie
There are a few individuals who are easily 10x more efficient in programming than the average.

Then there are some who have negative efficiencies.

Putting together a competent staff larger than two or three quickly becomes problematic.

2 posted on 04/09/2014 5:13:40 PM PDT by Paladin2
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

Plus mission creep.


3 posted on 04/09/2014 5:14:48 PM PDT by Cboldt
[ Post Reply | Private Reply | To 1 | View Replies]

To: Cboldt

yep, mission creep, plus on long term projects, technological advances and in some cases, obsoletion…..(is that a word)


4 posted on 04/09/2014 5:18:29 PM PDT by C. Edmund Wright (Tokyo Rove is more than a name, it's a GREAT WEBSITE)
[ Post Reply | Private Reply | To 3 | View Replies]

To: ImJustAnotherOkie
Software developers are among the smartest people on the planet

Oh, I could tell you stories ...

5 posted on 04/09/2014 5:19:19 PM PDT by ClearCase_guy
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

IT people [I call them Programming Weenies] have absolutely no clue as to what users want or need. They don’t live in the real world.

They take an established piece of software or a program, then put in all these unnecessary bells and whistles because they think it is neato-keen.

At the same time, they remove existing features that the users absolutely want and need - declaring them to be irrelevant. They also take existing features that they are going to keep and then put them in new places, so the users have to hunt-and-find them.

Then, they declare Victory ...


6 posted on 04/09/2014 5:21:46 PM PDT by Lmo56 (If ya wanna run with the big dawgs - ya gotta learn to piss in the tall grass ...)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

If you’re doing something that’s already been done by the same group it isn’t that hard to estimate time. When it is all a big unknown - that’s what you get for a time estimate... Bugs and/or poor documentation on interfaces to third party modules/sub systems can blow the whole thing up real fast time wise...


7 posted on 04/09/2014 5:23:31 PM PDT by DB
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

When they solve the problem of 90% of “software developers” being either barely able to string code together, or incapable of just “getting the job done”, then I’ll start listening.

Until then, 90% of estimates are crap, 90% of project deadlines are unrealistic, 90% of buzzwordy BS is exactly that, and 90% of “software developers” can keep finding another line of work.

And yes, ultimately we have fired or otherwise ensured the discontinuance of employment for 90% of the developers we’ve hired.


8 posted on 04/09/2014 5:24:47 PM PDT by TheZMan (Buy more ammo.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: Paladin2
Putting together a competent staff larger than two or three quickly becomes problematic.

Hence pair programming is as fair as teamwork can really go, heheh.

In all seriousness it's more like 10000x. 10x is more like novice programmer over clueless newbie...

9 posted on 04/09/2014 5:25:14 PM PDT by no-s (when democracy is displaced by tyranny, the armed citizen still gets to vote)
[ Post Reply | Private Reply | To 2 | View Replies]

To: Lmo56

I’m currently working with a full team that believes in this methodology. Aint life grand.


10 posted on 04/09/2014 5:25:49 PM PDT by TheZMan (Buy more ammo.)
[ Post Reply | Private Reply | To 6 | View Replies]

To: ImJustAnotherOkie
So how is it that despite such technical savvy and programming prowess, they are so woefully poor at project estimation?

Management.

11 posted on 04/09/2014 5:32:30 PM PDT by grobdriver (Where is Wilson Blair when you need him?)
[ Post Reply | Private Reply | To 1 | View Replies]

To: TheZMan
I’m currently working with a full team that believes in this methodology. Aint life grand.

And, when you point out a bug or flaw in the "New And Improved" software, they smile at you and call it a "Feature" - and then proceed to give you a 23-Step Rube Goldberg type "Workaround" instead of fixing the damn thing ...

12 posted on 04/09/2014 5:38:35 PM PDT by Lmo56 (If ya wanna run with the big dawgs - ya gotta learn to piss in the tall grass ...)
[ Post Reply | Private Reply | To 10 | View Replies]

To: ImJustAnotherOkie

I think the biggest factor in under-estimating software projects comes down to people: client expectations, software analyst’ skills in requirements-gathering, availability of business SMEs to help design and test, readability of the program, understanding of business rules and processes, etc. A good project manager has to properly manage the ENTIRE team, including the software development folks, as well as the customer.


13 posted on 04/09/2014 5:44:02 PM PDT by Lou L (Health "insurance" is NOT the same as health "care")
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

Mission/scope creep, constantly changing requirements from the client/business, levels of beauracracy that rival anything the government can throw in your way, and finally, multitudes of clueless, useless, counterproductive management.


14 posted on 04/09/2014 5:44:58 PM PDT by Sicon ("All animals are equal, but some animals are more equal than others." - G. Orwell)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie
My experience with cost/time overruns is that there is no really good way to gather requirements. And if you don't have good requirements you have no idea how long the project is going to take.

I've been on projects where we did detailed interviews and created massive, well-organized and detailed requirements. In most cases when we delivered the software we got a collective: "Huh? This is not what we asked for."

So then we tried the UI sample screens approach where we worked with them to identify what all of the user interface screens would look like, and collected the requirements through interaction with the clients. But then when we delivered the actual software, again we got the "Huh? This isn't what we wanted."

Until the users could actually interact with the application they really didn't grasp what they wanted it to do or how they wanted it to work. I really think it comes down to the fact that very few people are capable of thinking abstractly.

You almost have to build the application from scratch with continuous input from the user community to avoid rework. But of course the user community is already overworked and doesn't have time to spend helping you create the application that may eliminate their jobs.

So you gather enough requirements to get started knowing that whatever you build the first time will look nothing like the final version and you pray that the users will give your application enough time to identify all the missing requirements.

15 posted on 04/09/2014 5:46:12 PM PDT by who_would_fardels_bear
[ Post Reply | Private Reply | To 1 | View Replies]

To: Lmo56

You’ve played this game before, I see.


16 posted on 04/09/2014 5:52:01 PM PDT by TheZMan (Buy more ammo.)
[ Post Reply | Private Reply | To 12 | View Replies]

To: All

In my career in IT, the major issues leading to not bringing in a project on time and on budget are:

1. Broad finish dates driven by upper management, often management that is not in IT or does not have an IT background.

2. Failure of management to take the council of experienced IT professionals who do have experience in providing estimates. Often I have seen that given a set of broad requirements and a rough estimate that states “We estimate we can complete this project in x months”, management will state “That’s great. You will need to get this project done in 1/2 that time or 2/3 that time.

3. Poor requirements.

4. Scope creep, which quite often is driven from point 2.

5. Once it becomes obvious a project is in the ditch and will not come in on time, adding inexperienced resources in an attempt to cut the time to deliver. Adding these resources results in time wasted due to training new resources and rework.

I do find that developers often do underestimate the time needed to complete a task, but by the time a project is at the point of individual estimates for specific sets of work, the failure of a project has already been set in motion by factors far above estimates from a developer.

The article is interesting, but seems rather academic and not based upon the realities in business.


17 posted on 04/09/2014 5:52:40 PM PDT by WillVoteForFood
[ Post Reply | Private Reply | To 11 | View Replies]

To: All

In my career in IT, the major issues leading to not bringing in a project on time and on budget are:

1. Broad finish dates driven by upper management, often management that is not in IT or does not have an IT background.

2. Failure of management to take the council of experienced IT professionals who do have experience in providing estimates. Often I have seen that given a set of broad requirements and a rough estimate that states “We estimate we can complete this project in x months”, management will state “That’s great. You will need to get this project done in 1/2 that time or 2/3 that time.

3. Poor requirements.

4. Scope creep, which quite often is driven from point 2.

5. Once it becomes obvious a project is in the ditch and will not come in on time, adding inexperienced resources in an attempt to cut the time to deliver. Adding these resources results in time wasted due to training new resources and rework.

I do find that developers often do underestimate the time needed to complete a task, but by the time a project is at the point of individual estimates for specific sets of work, the failure of a project has already been set in motion by factors far above estimates from a developer.

The article is interesting, but seems rather academic and not based upon the realities in business.


18 posted on 04/09/2014 5:52:40 PM PDT by WillVoteForFood
[ Post Reply | Private Reply | To 11 | View Replies]

To: ImJustAnotherOkie
When a team does come up with a realistic estimate based on actual history, management can become incredulous and will reduce the estimate to a level they can live with.

MANAGEMENT will REDUCE the estimate! Winner! Winner! Chicken dinner!

19 posted on 04/09/2014 5:54:41 PM PDT by missnry (The truth will set you free ... and drive liberals crazy!)
[ Post Reply | Private Reply | To 1 | View Replies]

To: ImJustAnotherOkie

you gotta hire someone good just to spec it out BEFORE you can estimate how long to get it done (and how much)


20 posted on 04/09/2014 5:55:03 PM PDT by Mr. K (If you like your constitution, you can keep it...Period. PALIN/CRUZ 2016)
[ Post Reply | Private Reply | To 1 | View Replies]


Navigation: use the links below to view more comments.
first 1-2021-4041-6061-66 next last

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.

Free Republic
Browse · Search
General/Chat
Topics · Post Article

FreeRepublic, LLC, PO BOX 9771, FRESNO, CA 93794
FreeRepublic.com is powered by software copyright 2000-2008 John Robinson