Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Is 80/20 quality good enough?

By onyxruby in Culture
Thu Mar 22, 2001 at 03:50:50 AM EST
Tags: Culture (all tags)

I was having a discussion with a senior type person at one of the big 10 banks here in the US when, with dismay, he described the official philosophy guiding things in IT. When a project or task is 80% done, they move on to the next thing figuring 80% is "good enough". They call it the 80/20 rule and follow it religiously. Since this philosophy was thought up by the owner, it's not possible to "fix" it.

Unfortunately this has been bought hook line and sinker by the IT staff. The result is that things are never completed, never done correctly, and always slipshod. How do you maintain a high level of quality control when management doesn't want it?

In the real world there simply isn't time to do everything to perfection. At some point you must "get on with it". This skill of determining when to do this is probably one of the most valuable ones you can develop in this field. Unfortunately in some environments this gets taken to an extreme that precludes quality from entering the equation. We would never accept an IT component like a router, server, or atm service at 80%, so why do companies seem to want to accept this for IT work?

Judging quality of an IT professional is a bit more difficult than it is to judge the quality output of someone who makes things for a living. I think this is a challenge for most IT departments, and most IT people. I don't know how many times I have heard "quality is our #1 priority" only to hear that things can be "fixed later". It is only possible to have one ultimate priority, so how do you handle multiple priorities that are all more important than each other? I know there are some business owners and heads of IT that participate in K5, I would love to hear their perspective on this matter, to get the other side.

I don't make things for a living, but I take the quality of the work that I do just as seriously as any craftsman. Having a reputation of reliability has been enough to get me jobs based on references alone. This is by no means unique to me, and is actually quite common in this industry where reputation means everything. If I do slipshod work to accomodate unrealistic timetables, it could potentially damage my reputation for future jobs. What do you do when your employer only wants quantity, or is so eager to get on to the next thing that things are not allowed to be done correctly?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


o Is highly overrated, 0%
o Thats what patches are for 5%
o Is highly underrated 32%
o Means 5 9's 18%
o Is my highest priority 13%
o Customer service is supposed to sweep up the other 20% 1%
o Is worth every penny 18%
o Has it's place - right behind profit 9%

Votes: 91
Results | Other Polls

Related Links
o Also by onyxruby

Display: Sort:
Is 80/20 quality good enough? | 34 comments (34 topical, editorial, 0 hidden)
missing poll option (4.14 / 7) (#1)
by DesiredUsername on Wed Mar 21, 2001 at 08:11:55 PM EST

Quality is defined...
<x> by management.

Management is in charge of the show. If they tell you to do "80% of this job" and you do 100%, you didn't do what you were told, regardless of what you think is "right". This may sound like "just taking orders" but that's only because of the underlying assumptions to your argument. What is "right" about a technical solution is more than the technical aspects--there are political, social, financial, risk-analysis, ethical, etc. Management is in charge of the Big Picture, you are in charge of just the technical.

Play 囲碁
80% of what? (5.00 / 2) (#7)
by sigwinch on Wed Mar 21, 2001 at 09:19:11 PM EST

Management is in charge of the show. If they tell you to do "80% of this job" and you do 100%, you didn't do what you were told

But you get to choose the 20% that is not done. And therein lies salvation. If your boss says to shave 20% off, make it the right 20%. If it was me, I'd analyze the feature list on a cost-benefit basis, and kill the least profitable 20%. Boom, 20% of the cost instantly gone. Then I'd make up some reports, spreadsheets, and slides justifying it. If the boss lets you choose a reasonable way to measure the 20%, it'll work out just fine. If the boss measures the 20% by weighing a printout of the code base, then you'll have to do something like removing vertical whitespace, or using a smaller font.
It's standard practice on many software projects anyway. You start with a big list of "absolutely essential" features, overoptimistically schedule the development process, then drop less-desirable features as the deadline approaches.
The IT manager probably helps decide on the 100% level too. If a project shows up that looks like it can be fully scheduled in advance, you can always sneak in a complicated user interface "to be written as the last stage of the project". When it comes time to cut 20%, it'll be a good sacrificial lamb.
I'm not sure if this is the voice of experience or cynicism talking. Maybe they are the same thing. ;-)

I don't want the world, I just want your half.
[ Parent ]

have some self confidence! (none / 0) (#34)
by anonymous cowerd on Sun Apr 15, 2001 at 10:11:19 PM EST

I would never assume that my company's management knows enough about what's going on to micromanage anything. If they were that all-seeing, if they could do it all themselves, they wouldn't need subordinates, would they? And the management feel the same way; they value my judgment. On many occasions over the years, when I blatantly ignored their exact specifications for various jobs and did them my way, more thoroughly than they wanted but to the standard of quality I felt was appropriate, they accepted what I did with few complaints; and on a few occasions managers even came up later and said "I'm glad you did it like that; it really worked out well and we ended up saving a bunch of money!"

Come on, have a little confidence in your own judgment! My guess is, if you're a K5 reader, you're not just some damn burger flipper performing some mindless-labor job a machine could do. Hell, even if you are a burger flipper, keep in mind that you, with your five alert senses and your powerful underutilized brain, are in front of the grill watching them sizzle close-up, and the far off writer of that three-ring binder is not.

Yours WDK - WKiernan@concentric.net

"This calm way of flying will suit Japan well," said Zeppelin's granddaughter, Elisabeth Veil.
[ Parent ]

A request (4.28 / 7) (#2)
by finkployd on Wed Mar 21, 2001 at 08:13:12 PM EST

Could someone (not the author of the story, of course) who might happen to know please create a non traceable account and post the name of the bank with this policy? Just for my own bank selecting purposes :)


Sig: (This will get posted after your comments)
Its The Bank of Dogbert (4.50 / 2) (#4)
by eLuddite on Wed Mar 21, 2001 at 08:33:43 PM EST

Hello, how may we abuse your money?

Have you inquired of the Dogbert Retirement Fund? Briefly, not in as many words, you commit money to the fund and Dogbert retires.


Seriously, there used to be a time when the main frame guys guaranteed their work, absolutely positively. I blame it on the gradual disappearance of Cobol in favor of C.

God hates human rights.
[ Parent ]

heh (5.00 / 1) (#25)
by finkployd on Thu Mar 22, 2001 at 02:31:07 PM EST

Seriously, there used to be a time when the main frame guys guaranteed their work, absolutely positively. I blame it on the gradual disappearance of Cobol in favor of C.

We still do, and I code for the mainframe in C :)

Sig: (This will get posted after your comments)
[ Parent ]
Re: Its The Bank of Dogbert (3.00 / 1) (#27)
by mjg on Thu Mar 22, 2001 at 05:27:06 PM EST

Don't forget the disapperance of Algol and LINC too. ;-)

[ Parent ]
80/20 Rule misunderstood (4.64 / 14) (#3)
by jabber on Wed Mar 21, 2001 at 08:29:14 PM EST

The 80/20 Rule states that the first 80% of the job takes 80 % of the scheduled time, and the remaining 20% takes the other 80% of the time.. Which is why software projects are always late.

No, wait.. It's that 80% of the code contains 20% of the bugs and the remaining 20% of the code contains the remaining 80% of the bugs.. Yeah, which is why there are discrete 'trouble spots' in code, where debugging in concerned.

Oh, and 20% of the code handles the general 80% of cases while other 80% of code handles the 20% that is 'special cases'..

This last one is probably what your banking contact is mangling to say that 80% is as good as done.. Which of course is absolute BS, since the devil is in the details, and if control logic constitutes only 20% of the code, then they're all SOL.

I hope it's Chase. I really do. After they told me that they never received my last payment, while I held the processed check in my hand, I hope that the ignorant 80% of them show up for work the day after the remaining 20% run them into bankrupcy.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

Recent studies have shown... (5.00 / 6) (#11)
by elenchos on Wed Mar 21, 2001 at 10:32:08 PM EST

...that in fact the first 78% of the job takes closer to 17.8% of the time, and it is the last 22% that takes a whopping 82.2% of the time. This represents a change of 2.2 percentage points since the original publication of The Mythical Man Month.

Now with the bug thing, it has always been 81/19, not 80/20. That is how you can tell the suits, because they always think it is 80/20.

The last one however, is dead accurate. No more or less than 20% of the code ever handles anything less or more than 80% of the cases, whereas the other 80% of the code (this is by the line, by the way), is only for the 20% of the cases. Few modern programs will even parse correctly unless this law is followed and many young coders become stuck when they don't count the lines accurately enough, and so have, say, 125 lines handling 80% of their cases, but only 498 or 499 for the special cases. The thing with computers is that they are precise machines and a seemingly small error, in only one line of code such as in the 125/499 case, can have fatal results.

This to me points up a larger problem with the misunderstanding of statistics in society today, and the need to return to classic texts of statistical reasoning, such as How to Lie with Statistics.

[ Parent ]

marvelous (4.00 / 1) (#12)
by Arkady on Wed Mar 21, 2001 at 10:39:46 PM EST

That was funnier than anything posted to the Humor topic. The strictness; the pedantry. It's perfect.

Plus, you cite on of my favorite math books, and one which was actually used as a textbook in a stats class I took in college. So, that's a point in your favor right there.

And people have been whinging that we don't have a sense of humor here. ;-)


Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere Anarchy is loosed upon the world.

[ Parent ]
But you don't like the other book? :-( (3.00 / 1) (#13)
by elenchos on Wed Mar 21, 2001 at 11:01:42 PM EST

The Mythical Man Month is also a classic and one of the bestest and goodest ever books too. Everyone should read it and love it as much as I do. See also KC Cole's cool math book...

[ Parent ]

Classic Books (4.00 / 1) (#18)
by Mabb on Thu Mar 22, 2001 at 01:19:48 AM EST

The Mythical Man Month, Gerry Weinberg's "The Psychology of Computer Programming", and "Death March" by Ed Yourdon are all classics that should be required reading for budding developers.

If you really want to get into accurate estimation though, nothing compares to "Estimating Software Costs" by T. Capers Jones (1998: ISBN 0-07-913094-1). You will find Capers Jones quoted as THE estimation guru by all the software gurus. Not only that, it's 2.5 inches thick and 709 pages including appendices and makes a great paper weight :-)

QuiltBlog: WIP, SEX, WOW, MQ, LQS, HST...

[ Parent ]
Quality doesn't mean 100% (4.71 / 7) (#5)
by Miniluv on Wed Mar 21, 2001 at 09:06:09 PM EST

Depending on how that 80/20 rule is applied, it could be the best thing to ever happen to that IT department. If 80% produces a working product, which is fairly bug-free, does most everything you can ask of it, and nobody needs more then the reamining 20% is probably polish. There's nothing wrong with polish, but it's not something that must be the major focus of most products. Polish can come from a small number of employees working after the project has been taken off of top priority, because polish isn't the hardest thing to achieve.

You mention that nobody would tolerate 80% from a router or server, but I'm going to say you're wrong on that. Many, many shops tolerate far less than 80% of what a product could be. I'll give you an example from Cisco's line of routers. Almost every series of router they make, or stamp their name on, has multiple models at different price points. The most expensive has the complete featureset for that family, and you get a percentage less with each cheaper one, everyone knows how that works. Very few shops buy the top of the line model, however, because they don't need 100% of the features. Most people buy a router, switch, CSU, etc at about 80%, or a little lower, of total featureset.

So, if most people buy at 80%, why market a product at greater than 80% if it costs you extra time and money to get it to market? If people will be happy to buy your 80% effort, then that is what makes the most sense to stop at. This is why more and more software is going through public beta, because it helps a company know when they can stop adding features and start fixing bugs. It also tells them when they can stop fixing bugs and start the next version.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'

Is it really? (3.33 / 6) (#6)
by psicE on Wed Mar 21, 2001 at 09:16:20 PM EST

I thought the 80/20 rule was where 80% of people use 20% of the features, and 20% of people use 80% of the features. Supposedly, an efficient product would be designed with the 20% of the features built-in, which suits 80% of the people.

Is this a different 80/20 rule?

go forth and multiply (3.00 / 1) (#29)
by axxeman on Fri Mar 23, 2001 at 04:28:27 AM EST

The "80/20 rule" applies in so many different settings & situations it's just seriously not funny.

See, this is one of the 80% k5 comments which probably aren't worth anyone's while.

Being or not being married isn't going to stop bestiality or incest. --- FlightTest
[ Parent ]

IT serves the enterprise, not the customers (4.16 / 6) (#8)
by Keslin on Wed Mar 21, 2001 at 09:55:41 PM EST

It's important to keep in mind that management does not consider IT to be a 'craft', so whether an IT staffer is a 'craftsman' is really irrelevant. Management considers IT to be an enabling force, in the exact same way that the physical plant people are an enabling force.

The CEO doesn't care at all whether the guy that fixes the plumbing is doing a beautiful and elegant job of coming up with plumbing solutions, or whether that plumber follows every job to a thorough conclusion. The CEO only cares that the toilets flush when they are supposed to. He particularly cares that the toilets flush on board meeting days. The only time that he is ever going to really notice the plumber is when the toilet doesn't flush.

The IT department looks the same to the CEO, he only cares that the company web site works, that the printers all go when they need to, and that his email gets where it is supposed to go. Quality and craftsmanship aren't issues at all.

If the IT department was answering to marketing and actually producing products, then it would be a different story. Then, the quality of their work would be very important. If they are answering to the executive staff and functioning as an enabling force, it's a different story, as long as everything works correctly then quality and craftsmanship aren't important.

-Keslin, the naked nerd girl.

The Irony. (4.50 / 2) (#10)
by Paradocis on Wed Mar 21, 2001 at 10:29:44 PM EST

The CEO doesn't care at all whether the guy that fixes the plumbing is doing a beautiful and elegant job of coming up with plumbing solutions, or whether that plumber follows every job to a thorough conclusion. The CEO only cares that the toilets flush when they are supposed to.

What the CEO doesn't realize (and what often makes me want to evicerate him and hang him from a noose tied of his own intestines) it that these are very often the same thing.


"El sueño de la razon produce monstruos." -Goya

[ Parent ]
Of course (4.00 / 1) (#14)
by Keslin on Wed Mar 21, 2001 at 11:25:27 PM EST

Well, definitely, I agree that the quality standards that the IT department encourages within itself has a huge impact on how easy it is to keep things running. The more concerned your IT staffers are with craftmanship and pride, the easier it is for the IT department to provide acceptable service. That's really a second issue though. From the CEO's point of view, either the IT works, or the IT doesn't work.

What would be really nice, is if executives could understand the impact of quality on the bottom line. If that same CEO understood that he might save a few million by allowing his IT department to complete a quality job up front, instead of doing a quick-and-dirty installation and then patching it up for the next three years, then things might be a little different. Unfortunately, getting an executive to understand such an abstract, long-term concept is about as simple as getting a teenager to understand that smoking will kill them eventually. Like they care, at that point.

-Keslin, the naked nerd girl.

[ Parent ]
w00t :) (1.00 / 4) (#30)
by axxeman on Fri Mar 23, 2001 at 04:58:24 AM EST

Oh my! You're a naked nerd girl! "l33t"!

Being or not being married isn't going to stop bestiality or incest. --- FlightTest
[ Parent ]

hmmm (none / 0) (#32)
by axxeman on Mon Mar 26, 2001 at 04:54:16 AM EST

I think I need to cut down on the subtleties...

Being or not being married isn't going to stop bestiality or incest. --- FlightTest
[ Parent ]

good question (5.00 / 8) (#9)
by Arkady on Wed Mar 21, 2001 at 10:27:06 PM EST

But none of your poll answers really synch with me. I think the best statement of my attitude is:

   Do what you can, with what you've got, where you are.

Possibly that's from T. Roosevelt, but I can never remember where I heard it.

It's a good summary of how I think of this, though. Quality is only important to the extent that it's feasible (insert whatever criterion for _that_ decision you want). If you have the time and the tools to build a perfect solution, then you should. If you only have enough to get it working ling enough to fix it as you go, that works too. After all, it's the best that you've got the resources for.

This is basically the attitutude we took setting up the OpenNIC. None of us can afford the massive servers and network pipes that the ICANN/VGR system suns on, so we designed it to get its reliability from being a widely distrubted collection of smaller servers on smaller networks. After all, getting DSL is generally cheap and easy amd so is a Pentium with a free *nix on it.

The system works, and that gets us the time to improve it to the point where we'd like it to be in the end _while_ we get to use it in the meantime. This has been called the "New Jersey" app-roach, and this is the first time I've ever espoused it, but it's the best way to go when your resources are limited.

OK, that's longer than I'd intended it to be but it pretty well sums up my attitude to this. Good question to ask.


Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere Anarchy is loosed upon the world.

OT: The quote (3.00 / 2) (#19)
by gblues on Thu Mar 22, 2001 at 02:00:16 AM EST

Well, according to Google, the quote, "Do what you can, with what you've got, where you are,"
seems to be popularly attributed to Theodore Roosevelt.

... although in retrospect, having sex to the news was probably doomed to fail from the get-go. --squinky
[ Parent ]
Bloat (2.25 / 4) (#15)
by finial on Wed Mar 21, 2001 at 11:57:47 PM EST

The design was probably bloated with feature creep to begin with so by cutting it 20%, you end up even.

Time Value of Software (4.83 / 6) (#16)
by Bad Harmony on Thu Mar 22, 2001 at 12:11:08 AM EST

For some applications, 80% of the software today can be more valuable than 100% of the software in 3 months.

For example, an application that reduces the gate count of chip designs by 50%, or one that accurately predicts changes in the price of a commodity.

54º40' or Fight!

Quality is in the eye of the owner (4.33 / 6) (#17)
by Mabb on Thu Mar 22, 2001 at 12:30:01 AM EST

Steve McConnell and Ed Yourdon have some interesting things to say about developer "gold-plating" and "good enough" software development, respectively. Have a look at "Death March" by Yourdon and "Rapid Development" by McConnell if you haven't aready. It's the eternal conflict of personalities in software development projects. I've seen both swinging way too far to one end of the pendulum and I'm normally in the middle as Project Manager.

I must say I have little respect for %complete statements in a project plan and never used them in my status reporting, despite the warm and fuzzy feeling they give to management. Software development is not a linear task so I usually break down tasks into small units that can be set to done or not done in the project plan. I also always have a priority list of must haves, should haves, and nice to haves and all functionality is rated as such in the requirements and spec documents. The ratings are gathered from the business as well as IT since business is not likely to know the technical dependancies. First call on priorities does go to the business though.

The customer/business unit has the right to call on timing and release issues, however it is the developer's responsibility to advise them of the risks of early releases and missing functionality. If business accepts the risks then documentation of the agreement is mandatory. If your project manager is not documenting such agreements then I'd be on their back about it. Constantly.

It's all about negotiation. In this case, it sounds like their 80/20 thing has become a set rule for lazy business people who don't want to have to think about risk and consequences and who probably feel they can pass the buck on failures to IT anyway. Don't let 'em!

QuiltBlog: WIP, SEX, WOW, MQ, LQS, HST...

It's always been like this... (4.33 / 3) (#20)
by deefer on Thu Mar 22, 2001 at 06:42:21 AM EST

I've been working in the industry for seven years now, and I've done a lot of consulting for many institutions and banks.

When I first graduated, I was very much concerned with writing *perfect* code. Unfortunately, my project manager wasn't of the same opinion and wanted just code that worked. So it took about 2 years before I understood why this was - being technical and taking pride in my job were all I was concerned with. But the manager had deadlines, resourcing and costing issues to consider, things I was not party to. It still hurts putting code live that you know is not your finest, to this day.

This is the cost of selling your skills to a company - you must do their bidding, even if it doesn't feel good on release day. You do the best you can to stop feeling like a corporate whore by putting extra hours in so you can feel good about at least some of your code.

I think that this is why Open Source has such a following - many projects do not have fixed deadlines, they are labours of love for their coders. And Open Source gets the bonuses of that - who will write the best code on average, the code jockey doing 9-5 and being overruled on how things are being done, or the hacker in their bedroom doing it because it is part of them? I know for sure that any code I release Open Source I have more pride in than what I write commercially - every person who releases code as Open Source does so with a small part of them wanting some props from other coders - it gives us warm fuzzies when someone else thinks your code is good, and only coders can give that appreciation.

So anyway, while there are deadlines, costs and politics involved, 80/20 is sometimes as good as it gets. But remove all issues other than technical and you can write the perfect code that tickles the hackerthalamus part of the brain... I think it is best summed up as "Good quality, quick delivery, cheap - pick two". Wish I knew who said that!

Kill the baddies.
Get the girl.
And save the entire planet.

and always will be.. (3.50 / 2) (#23)
by flyhmstr on Thu Mar 22, 2001 at 08:09:38 AM EST

I know this from both sides of the fence, my position within my company is such that I'm on the PHB side of the fence and what I'm looking for is code which works, does the job but may not be as 'finished' or slick as it could / should be.

If there are critical bugs which are affecting the end users then they obviously need fixing, however a minor buglette which only appears a few times a year and only takes 10-15 minutes of admin time to correct the problem it's not worth fixing.

In my other life I've been part of the net community for a number of years and contributed to various things and I can aim for a 'better' quality of output. Though it shouldn't be said there are no timescales for open source, "release early and release often" is the credo open source needs to follow to keep things rolling.

[ Parent ]

Which company is this...? (3.50 / 2) (#21)
by joto on Thu Mar 22, 2001 at 07:05:22 AM EST

There is little reason to aim for perfection in anything. In fact, the only reason I can think of is good old-fashioned work ethics, but if your aim is profits, as it is for most companies, then aiming for 80% seems like a good idea.

Software development is so god damn expensive! Figuring out those last 20% might easily take 80% of the time. A software system is usually something that replaces some other manual labour. For this to be cost-effective, there is a trade-off between the price of the software system and the manual labour it saves. Usually this tradeoff will result in some seriously crappy stuff that barely manages to do it's intended purpose. But as long as it can do that, there seems to be little economic incentive to develop it further.

It is certainly depressive for someone who actually has good work ethics to live in an age where crappy software is good software engineering, but it seems to be something that will remain true for the inevitable future (and it also remains true for most other people who take pride in their handywork as people generally buy the cheap stuff instead). And if I were in a purchasing position, even I would certainly consider a company stating their philosophy something like this:

" We don't aim for the best software! We might even have more bugs than our competitors! But we deliver on time, and on budget! "

So, while perhaps not your ideal workplace (academics, perhaps), most likely the company is already succesful. Where can I buy stocks?

Well, as a general rule... (4.60 / 5) (#22)
by joshv on Thu Mar 22, 2001 at 07:28:45 AM EST

As a general rule, 80/20 is true, and those who ignore it are doomed to waste much of their time in non-productive activities. Is it always 80/20? Should you apply this rule religiously and tell developers to lop off 20%? Of course not.

80/20 is merely a recognition of the asymptotic approach to perfection, in almost any line of work, software development in particular. That last 10 or 20% could could cost you are much money/time as the first 90 or 80%. And lets not talk about the final 1%...

Now, this is not to say that you should throw quality out the window, just that *real* quality is extremely expensive, something like 10 times more than the average cost per line of code. Check out NASA's Space Shuttle coding group for an example. I think something like 8 or 9 bugs have made it through to production code in the decades they have been at work. That's amazing, but in a business environment you simply don't need to be that good, and you certainly don't have the money or time to spend to get there.

Knowing when to stop is hard, and as another poster said, is most of what makes distinguishes the good from the bad in project management.


The last 10% of the work takes 90% of the time (4.00 / 2) (#24)
by mblase on Thu Mar 22, 2001 at 09:46:47 AM EST

...this is a rule all coders should know and live by. The first 80-90% of any project is straightforward, once the outline is in place. You build that much rapidly, with few revisions.

The last 10-20% is modifications, debugging, revising, user-feedbacking, and usability-testing. It takes just as long as everything that preceded it, if not longer. It's not necessarily harder work, but it's time-consuming and takes more patience and organization.

If you're using an 80/20 rule, then, you're starting a new project's infrastructure at the same time you're working on the last project's fine-tuning. This is fine, since you're not doing the same work on both projects, but your managers should be aware that by no means is a project 80% done time-wise just because it's 80% done work-wise.

[ Parent ]

80/20 is too subjective. (3.33 / 3) (#26)
by Rasvar on Thu Mar 22, 2001 at 05:08:07 PM EST

The problem is what is in the "20" part. We implemented a whole "workstation" platform at my company back in 1999. A software mangement system was suppose to be the key to making the project work. However, that part ended falling into the 20 area because they wanted the systems out. Mind you, there was no "immediate" need for these systems other then the fact that they wanted to go to Outlook for email versus another platform that was functioning well. Rather than wait six months to the the mangement system working, they pushed the project out. Three months later, when they were finally ready to roll out the management system, they realized they blew it. Every system would require a reload of NT to work. We are talking 120,000 systems. Obviously, that was not going to work. It has taken until now, 2001, to get close to implementing this important peice. Without this piece, we have wasted millions and millions of dollars in manpower, trips and reloads because this system was not available to us from day one.

80/20 has a use; but, you sometimes have to throw that out if a major item is not working. I am not fond of 80/20 becuase it has been abused by clueless mangement. I don't trust them to implement it correctly. 80/20 done right is very efficient. 80/20 done poorly is worse than nothing at all!

As a software quality assurance engineer... (3.00 / 2) (#28)
by tippiedog on Thu Mar 22, 2001 at 06:23:32 PM EST

There are always going to be compromises, tasks that cannot be finished, or done as well as one would like. As a software QA engineer, it's my role to ensure that those who make decisions about such compromises have as much information as possible: number of known outstanding issues, severity and anticipated user impact of each, etc. Making a well-informed decision is the key.

Over the years, I've seen QA engineer who just couldn't get their heads around the idea that a product would ship while there were still known defects in it. In my not-so-humble opinion, those people will never go as far as those of us who can detail risks, etc.

It depends on the project (5.00 / 1) (#31)
by Jim Wayne on Mon Mar 26, 2001 at 12:02:42 AM EST

Whether the 80/20 rule applies depends on the project. For example:

1. You are designing a building. If you leave off 20% of the design, you may end up with a building that lacks the functions you need for it to have.

2. You are buying groceries. If you get the most vital 80% of the list (bread, milk, etc.), you'll probably do all right. You can get the other items on your next trip.

3. You are operating on someone's brain. Getting it less than 100% right is unacceptable to the patient.

4. In my personal opinion, a bank that handles my accounts with only 80% accuracy will soon lose my business.

5. A laundry that gets only 80% of the customer's clothes back to the customer will soon have little business.

6. On the other hand, if I get up 80% of the weeds in my lawn, I'll be delighted.

The problem here seems to be that the organization has made it a rule, which is followed without exception. So vital, central, necessary projects, upon which the future of the company depends get only 80% done, and minor, trivial, nice-but-not-necessary projects get 80% done. In the first case, you kill your company. In the second case, you waste a lot of time on nonessentials.

The management here is trying to make a rule that will do what the managers are supposed to do. It is the job of managers to say when a project has reached an acceptable level of completion, whether that level is 40% or 99% percent.

This kind of thinking is a sign of moribund management.


There was no golden age. There will be no golden age. All ages are alloys. But some alloys are better, stronger, and more useful than others.

80/20 Rule (none / 0) (#33)
by steveaustin on Wed Apr 04, 2001 at 04:07:44 PM EST

As technical minds who take pride in out coding and our conduct in the technical world we must always take such rules with a hefty granual of salt. Remeber, of course managers follow the 80.20 rule, the first thing a manager learns is the " us and them" routine. becuase they themselves do not have direct ownership of the work in question. yes we can wieght the pros and cons some other time but as I worked for some very big intitutions it is becoming surpisingly clear that managers for the most part see the tech as a tool at their disposal they are not worried about how you feel about your work....There moto "just get it done!".
---- seymor was going to tear into it like bag of frozen peas, unfortunately it was a sack of potato's a factor he wasn't prepared for.
Is 80/20 quality good enough? | 34 comments (34 topical, 0 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!