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 ...
I think that our profession requires a fairly rare combination of the (sometimes) wildly creative part of the brain (the part that conceives of the solution(s)) and the disciplined part of the brain that ensures that the implemented solution is robust, efficient, resistent to errors, and maintainable. Quite rare, and quite valuable.
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.
COBOL Rules!
(I would write "Hello World", but it would take 5 pages of code and my carpal tunnel is acting up again)
L,u. A0, $cas(’COBOL rules’)
LXI,u A0, 0103
ER aprint$
(No, it doesn’t)
Ding ding ding. We have a winner.
Lots of non-programmers do this. In my experience, it’s been primarily managers and visual designers.
I had a manager who thought it would be a good idea to refactor my requirement satisfying enhancement after deadline (which I did meet by the way), because he thought it would easy and it would be cleaner that way. He disregarded my advice and turned a 2 day assignment turned into a 5 day one.
I also had a visual designer decide to not use Android’s UI element designed for what we wanted, because he didn’t like the way it looked. I explained to him that it is not in our best interests to create customized UI components for trivial reasons. Future versions of the OS could come out and easily break it (That happened to our iOS team A LOT)..
He just said do it and delayed the project for days.
In a more agile discipline, the number of features is subject to change, while the deadline and quality stay constant. So, there is always a quality product to deliver to a customer at the end of an release; it just may not have everything you want. However, I am not aware of any company that works this way and it’s because of the people who don’t program.
It usually goes like:
“I don’t know.”
“Why not?”
“Because I can’t see the future. If I could, I wouldn’t be working here.”
“Just guess.”
(A high number)
“Why do you think it is going to take a long time?”
“Things usually go wrong.”
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.
show me one major software project that managers didn’t pull resources away from, one project that didn’t have fundamental requirements change along the way, demands to add in or do something major that wasn’t in the original scope (scope creep), show me one major project that doesn’t have enough resources allocated to do proper testing and integration, between teams, and between user testing.
it aint b/c of software engineers not estimating properly.
I think this title may vary from company to company; in my experience, this role may also be called a business analyst, a business integrator, an information analyst, and so forth. This role is the person who sits with the client to elicit and capture requirements which will be used to develop the software.
Just remember, there's a cost associated with being specific. Software development--much like carpentry--is a field where "measuring twice and cutting once" often applies. In software development however, the "measuring" is the requirements-gathering, design, and probably testing. These aren't the "sexy" parts of software development, but accuracy pays off here.
Unfortunately, these up-front activities are often areas where timelines and budgets get cut the most. Customers don't want to hear that it'll take six months of planning and user meetings before any code is written. Obviously, that depends on your development methodology, but I hope you get my point.
To me, the problem is almost always the requirements. The customer fails to spell out clearly what they need. Management fails to spell out clearly what is desired. Coders do what seems to be stated in the requirements.
It’s the blind men inspecting the elephant syndrome - each only understands a small piece, none understanding the entirety.
Oh - and the managers that make the schedules (often with no input from the developers) are too eager to sign up for whatever will get them noticed - agreeing to nonsense deadlines because they don’t have the fortitude to say “can’t be done”.
Most of the time, I find it is because the users are thinking in terms of design, and not in terms of function. They concentrate on what the program will look like, and not what it will produce to make their lives better.
I am on a personal mission to "fix" the requirements in the aerospace software industry, one classroom of practitioners at a time...
In my experience, the most common reasons a software develop under-estimates are:
1) They over-estimate their own capacity. Primarily, they assume 100% of their time goes into the problem at hand. In truth, you’re lucky to get 75% because of general overhead, distractions, meetings, and so on.
2) They look at only the code design/writing/testing time and forget to include additional process steps that aren’t “writing software” but nevertheless have to get done. Documentation, configuration management, QA, and so on.
3) Rampant optimism. Typically, a developer will give an estimate how how long something SHOULD take, assuming everything goes well. In reality, very few things go well, so estimates tend to be under more often than they’re over.
Because of these three, I only half joke when I say the way to get the true estimate is to take the developer’s estimate, multiply by 2, add one, and then change to the next higher-order unit. For example: a 1-hour developer task might take a full 3 days to get through the entire process.
100% accurate.
Plus, actual Programmers, as opposed to coders are fairly scarce as a percentage of the population in question.
Programming is part art, part science.
And testers usually take it in the back end, on the back end.
“Who tested this” gets asked far more than “who coded this”
Rebuilding existing functionality, or at least cleaning it out, from the detritus, is something good programers should do on the sly when the opportunity presents itself.....
It’s thankless, and goes unnoticed. But the sublime satisfaction, and making your life easier going forward is ample reward enough.
bump for later.
Of course if you accept the article’s facts that software engineer’s do the estimating. In my experience they don’t.
Engineer’s estimates are sort of like the first level of a rumor that morphs. Usually they are told an end date dictated by some executive’s(Type A) promise.
What’s the only thing dumber than an end user?
Two End Users....
Programmers give bad estimates because they’re optimists. They’re paid problem solvers and they problems as solvable and with confidence in their abilities they under estimate. I’m QA, we’re pessimists, we over estimate.
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.