What is Digg?22 Comments
- jarva, on 10/12/2007, -1/+11Direct Link
http://blog.screen-scraper.com/2006/08/24/developing-software-by-the-15-rule/ - JimmyLin, on 10/12/2007, -2/+12Hmm.... Vista should already have passed the 150% mark then...
- bpapa, on 10/12/2007, -0/+5Oh, I thought the 15% rule was to create a blog post that links to another article, where your blog post is 15% as long as the original article. Then post your lame blog entry to Digg.
- jawadde, on 10/12/2007, -3/+747.6% of all statistics are made up on the spot.
or to quote Churchill : "the only statistics I believe, are the ones I made up myself." - klang, on 10/12/2007, -1/+5This is not a question of making statistics up on the spot. If I have to estimate a job, I add 50%. Estimating a job is far more difficult than doing the job. Experience is the only thing that counts here.
- mcherm, on 10/12/2007, -1/+5Most everyone does this. What's unique here is that eKiwi apparently gives an "accurate" estimate up front then allows up to 15% overage without objection. Most developers include a 15% padding in their estimates (or, more realistically, a 30-50% padding... sad but true).
- phaed, on 10/12/2007, -0/+3noobs + Software Engineering 101 + a bit of experience = client repelling manifesto
- SlowOnTheUptake, on 10/12/2007, -0/+3I'd be interested in seeing the level of detail provided in the "Statement of Work." At first blush it sounds like the policy translates into: "if we underestimated the work required (or our ability to do it) or otherwise failed to control the project so that our loss will be greater than 15%, we will renege on our obligations to you." There must be more to it than that. The problem, and maybe I'm just misinterpreting the article, is that it sounds like they let things go until they've spent 115% of the budget and they they start get "hard-nosed."
I've been on both sides of the table on contract issues like this on dozens of occasions, more often as the supplier and I can't see a blanket rule like this being of much practical use but it would be nice it it were.
What does seem to work is much more detailed project control in the early phases of the project, clearly defined milestones and strict management (in particular, insisting on fully signed-off specs from the customer which become part of the statement of work.)
Customers wishing a more open ended approach should consider the "Scrum process" approach and control their own budgets. - purplelantern, on 10/12/2007, -1/+4This smack of re-inventing the wheel. The extra 15% is simply "contingency" in standard project management speak. You come up with your estimation based on the project plan and time line. Then you add 10% contingency in terms of time/fee. The client see it (and pay for it) because it is transparent. The 15% the way described in the article is bad because it is a hidden fee.
Try explain this "15% rule" to a confused client because he has never heard of it before and have him eventually comes back with a "OH! You mean a contingency!" That would be embarassing and unprofessional. - mos6507, on 10/12/2007, -0/+2That's how Scotty gives his ETAs.
- coding, on 10/12/2007, -0/+2This is just another group trying to name something that doesn't exist or even need to be named. Kind of another buzzphrase.
- yourowndisaster, on 10/12/2007, -0/+1Direct Link Mirror.
http://www.yourowndisaster.com/mirror/blog.screen-scraper.com/2006/08/24/developing-software-by-the-15-rule/ - rtfx, on 10/12/2007, -0/+1If you want real information on software estimation, try a book written by an expert:
http://www.amazon.com/Estimating-Software-Intensive-Systems-Processes-Engineering/dp/0201703122/ref=pd_sim_b_2/102-1298081-8833743?ie=UTF8 - timberfish, on 10/12/2007, -0/+1I show the video was removed by the YouTube user. Anyone know why?
- cbmeeks, on 10/12/2007, -0/+1er, didn't every developer already know that? They got a front-page digg for telling us they bump up projects 15%?
You'd be stupid not to.
no diggy
cbmeeks
http://www.codershangout.com - elfn, on 10/12/2007, -0/+1Stupid blogs.
- vari007, on 10/12/2007, -0/+0its a good rule though in theory, in practice it turns to more than that padding.
- diggdisc, on 10/12/2007, -1/+0It's called the 20% rule and it been standard practice for a long, long time not just in software. It goes not only for development length timeline, but applies to all sorts of phases in the development cycle. Including requirements.
- rwalling, on 10/12/2007, -1/+0I think you're missing the point, purplelantern.
In general there are two types of project quotes: fixed price and hourly. With fixed price the developer quotes a hard dollar amount and if he exceeds that number without prior approval (a "change order"), then he eats it. Hourly contracts are typically an estimate of how many hours it will take to do the work, but if you're doing things right there's always a clause at the end saying "If we exceed this amount we can work additional hours at $X per hour."
You are referring to hard estimates, which do tend to have contingency built in.
This document is referring to hourly contracts which typically have a smaller margin since they have "give" on the top end. With that in mind, the 15% is not a contingency fee, it's work that will be done for free if the estimate is exceeded. The idea is that the client does not have to pay for the first 15% of hours over the original estimate, thereby sharing the risk between the developer and the client.
Finally, the rest of the manifesto, and the real reason it caught my eye, is that it's written in plain, casual English. I have bullet points at the end of my contracts that say a lot of the same things, but they're cold, hard, and contractual. This document is much more of a relationship-builder and it's a style I'm going to use in the future with my clients.
Most people would never think to put a "We're Going to Be Nice to You" section in a client document. This is a great use of transparency. - hobnob, on 10/12/2007, -5/+0hahhaha unf
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is