I think the saying may have been mistyped. “the first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent” It is saying that the whole project is 180%. It should read “the first ninety percent of the task takes 10 percent of the time, and the last ten percent takes the other 90 percent”.
It just sounds funny if a person has not heard the saying.
“It just sounds funny if a person has not heard the saying.”
Umm, it’s supposed to sound funny. It conveys that idea that the totality of the project (100%) was miscalculated from the start.
The quote, as I remember it from McConnell’s Code Complete is:
“The first ninety percent of the project takes the first ninety percent of the time. The remaining ten percent of the project takes the other ninety percent of the time”
Yes, it is intended that the “times” don’t add to 100%.
As a point of interest to myself, why did McConnell remove the qoutes in the latest edition of Code Complete? I found that I would go back to the book looking for a quote I remembered and then rediscover some section of the text that was appropriate to my problem at hand or that I needed a refresher in. Without the quotes, I find I don’t return to the book as often.
Steve updates his list of classic mistakes for 2008
I’m getting cynical about some of those points.
Does it make me an “Uncontrolled problem employees” when I roll my eyes and laugh every time management commits “Push me, pull me negotiation”, defines “Overly optimistic schedules”, “Shortchanges upstream activities” and other sins?
Probably. I’ll try not to laugh next time. 
One thing I did not expect to learn about when I finished Uni and started my career: human psychology!
Paul: ‘For example, “research-oriented development” is a direct side effect of what might be called CV (Curriculum Vitae) Syndrome - the desire of developers to work on the “latest and greatest” stuff so they can keep their resumes up to date with the latest or most in demand buzzwords.’
That’s a little heavy on the cynicism. I seriously doubt that many developers have their resume in mind when they decide how to solve a problem, especially considering that any potential future employer is going to care more about the project requirements and success, not what technologies it used.
You want developers who love to be on the bleeding edge. They are motivated and interested, two things that are very hard to find in the industry. You just have to keep them in check, and relegate the experimentation to less critical projects.
Jrn: “The expert writes code that works today and refactors it tomorrow and every time he needs to add something, always aiming for the simple and clean solution.”
To Skeptic and Sushant Bhatia, read the links at the top of the page. They explain what these things mean.
http://www.stevemcconnell.com/rdenum.htm
http://www.stevemcconnell.com/rdmistak.htm
Are we learning from these mistakes? It seems to me that the list is expanding, not contracting.
Switch to antoher career if you want to get off the island.
I loved the Robot episode (of Gilligan’s).
You know what the biggest problem in coding is these days, that far surpasses any of these?
The fact by US law, a CEO - and therefore indirectly, all management under that CEO - must always act in the best financial interest of the stock holders, unless forbidden by the stockholders from doing so. Should the CEO favor long-term or short-term profit? That question ends up answered by another: Will today’s stock holders be stock holders in a few more quarters?
Sadly, the mistakes of the past are so tempting because more often than not, they get crap on the shelf, albeit in a shoddy condition. In a market where companies routinely plaster their products with disclaimers, warnings, and license agreements making it clear that you shouldn’t ever rely that the product even function, let alone function well, how the hell is anyone ever supposed to expect quality?
The modern IT consumer ends up raving happy just to get a product that works out of the box, works properly, and continues to work. That is to say, the customer is so used to getting shafted by the industry that shoddy goods are the norm and something that ought to be merely acceptable is regarded as excellence.
The opposite happens from time to time, however… customers who’ve totally been had with an overpriced IT bauble will rant and rave about some new feature they claim to love to hide the shame of purchasing a product that, while it has that excellent new feature, completely fails to deliver up to expected standards in its other base functionality.
Programmers whine and bitch like children about crap like the last 10% of the job being 90% of the effort, but face facts: you people ship stuff with bugs anyways, so its complete bullshit to count that last 10% as part of the development time; its more like, part of the “We sold you broken shit and now we have to fix it after the fact” service call.
Take a look at how many days, months, years go into bringing something to market from conception of the idea in a field like medicine. It doesn’t exactly take too much time to go from “chemical in a test tube” to “bound agent in an unlicensed pill”, but take a look at the quality control efforts, product testing, approvals procedures, the massive time, effort, and expense involved in seeing if its worth it at all, it its going to work right, learning all the kinks and oddities of the product.
Outside of NASA and the medical field, where else has this sort of attention ever been paid to software development? Because THATS how its done RIGHT, when its done RIGHT. The rest of you whiners are just selling broken junk, and you know it.