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?
Then there are some who have negative efficiencies.
Putting together a competent staff larger than two or three quickly becomes problematic.
Plus mission creep.
Oh, I could tell you stories ...
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 ...
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...
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.
Management.
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.
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.
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.
MANAGEMENT will REDUCE the estimate! Winner! Winner! Chicken dinner!
you gotta hire someone good just to spec it out BEFORE you can estimate how long to get it done (and how much)
REM The standard response that we always got from the boys and girls at Lawrence Livermore Labs - six months, a million bucks. Someone usually wrote them a check.
Since software is easy to change, management will change the target often at the slightest whim of the customer. Mechanical or electical managers are much better at telling upper level management “we’ve already had the dies made. Your ‘little tweak’ will cost $30,000 and set us back six weeks. Are you sure you really want this?” Software’s flexibility is used as an excuse to skip the design phase or to throw aside the design when the code is being written.
My rule of thumb as a CFO was to double their estimates of time and cost. Worked every time.
5.56mm
Its actually the inverse Peter principle. Instead of getting promoted from competence to incompetence, they get promoted out of incompetence to a place where they can do less damage.
A couple of thoughts:
(BTW, I have been doing S/W development for 45 years and counting, and in my first 30 years I put in 15 years of un-compensated overtime; that’s 45 years of experience during that time plus the last 15 years of “normal” work. That’s 60 years equivalent experience by my count)
Why is it that the only people who know how to do S/W development better than those of us who actually do it is EVERYONE WHO HAS NEVER TRIED IT!?
And, they NEVER tire of telling us how easy it is. sigh.
The reason estimates are guaranteed to be off is because the software to satisfy a given set of requirements (usually a rough wild-assed-guess), composed of what the user thinks they want and never what they NEED, have NEVER been created by this development team, for this customer/user group, using these tools, on this platform, using this data, etc. EACH new project/requirement is UNIQUE! If it had been done before we would just go get that solution and be done. It’s not like an estimate to build 6 more houses like the last 50 that this crew built on the last project.
Why is it that the estimate (wild-assed-guess) is given more credibility than the work product that delivers the needed capability. It makes me think that the critics are all libs/progressives (live in a dream world) and the development team is conservative (forced to live with reality).
Sorry to rant.
Because at every step in the process - Requirements Development, Coding, Testing, there’s never time to do it right, but always time to do it over.
I appreciate the tremendous insight I am reading on this post. Apparently we have quite a few Freepers with firsthand knowledge of the programming business.
“So how is it that despite such technical savvy and programming prowess, they are so woefully poor at project estimation?”
I will add this to the other comments. It is possible to come in under budget and in less time than estimated. It is also possible to come in over budget and finish in more time than estimated. However, it is impossible to come in at less than zero cost or to be finished before you start. And it is possible to take infinite time and incur infinite costs. Thus, on average, estimates tend to be less than the actual results. The more specific we can be when planning and closer to existing, real-world projects in scope, the closer the estimates will be also.