The Old Joel on Software Forum: Part 4 (of 5) - perfectionism vs. good enough

perfectionism vs. good enough

Assume for a minute that some definitions exist:

good enough: The fuzzy range of software goodness which your customers are willing to accept your product and pay the negotiated price.

perfectionism: The software goodness required by which your best developer would showcase her software in a trade journal.

So...

Is there not room for both? I mean a healthy software environment should consist of a tension between perfectionism and good enough.

Aren't software aware managers secretly happy that their developers:

1. Trying to check in code clean up, sneaking in clean ups when fixing bugs during bug fix for ship cycles.
2. Are never satisfied with code quality?
3. Persist in their desire to add features even when the code is "feature complete".
4. Never satisfied, sometimes whining about crappy design, pressing for re-writes that add no perceived value to product.
5. Worry about things no one has thought about yet: "invisible" features like security, scalability, performance under load, etc.
6. Others?

Can you imagine working with a team of developers that consistently say "yeah, its a bug - but not worth fixing". That's the manager's job! The manager is the one who should be putting the brakes on the dev team. A dev team that tends toward imperfectionism? I don't think I wanna be there. They should be driven - its their passion for cool features, performance, clean code, ... that are part of the dynamic tension that keeps the organization honest. Take it away, and I say one of the wheels falls off the wagon. And a 3 wheeled wagon ain't no fun to ride.

Perfectionism? Should be one of the hallmarks a good developer. Not that you indulge their every fancy - but they should at least lean that way. If you don't hear some young developer say "this needs a re-write" every now and then, you might check to see if they have a pulse.

hoser
Saturday, April 24, 2004

A good developer simply knows when to say, "It's good enough, the customer will pay for it, now we have to make some money." Of course they have this feeling that is tugging at them saying, "Could do this better or that needs to be implemented in the next release cycle..."

Here's the clincher:

Anyone who takes pride in their work has that nagging feeling that they can do a better job. These very people find ways to do a better job in the time allotted them to complete a given task. This is because they are smart, they are not afraid to change, they learn fast and of course they get things done.

The problem with perfectionism is that it implies unlimited time and resources. Of course we all know that in the world of business, especially in the emerging global economy, there is no such thing.

It's just easier than dealing with the pain.
Saturday, April 24, 2004

In college, I took a drawing class. I kept focusing in on one area and trying to make it really detailed, like a person's face and he kept telling me that I have to move in & out, I can't focus on one area too much, I have to step back & look at the whole picture too. Maybe do a little over here, a little over there, but never just focus on one area for too long.

I think this is what Joel is talking about. Taking a step back and looking at the whole picture. Don't just work on what's in front of your face, try to figure out what really needs to be done first.

www.MarkTAW.com
Saturday, April 24, 2004

"Taking a step back and looking at the whole picture."

Yep, that says it all.

If you always understand the tradeoffs, having a DESIRE to have it perfect is wonderful. But when that desire becomes an obsession or you're oblivious to the COST of that perfectionism, then you end up with a super fast elegant program that doesn't solve a real problem (b/c someone skimped on the requirements analysis) or you never finish it.

Cost. Schedule. Features.

Pick any two.
Maximize any one.

Mr. Analogy
Saturday, April 24, 2004

Frankly, I think perfectionism doesn't exist, and it's a buzzword. It's always a lot easier to ascribe a flaw in process or product development to some wild irrationality, than it is to figure out what's actually wrong.

In my experience, if a product succumbs to so-called perfectionism, it's because there was a lack of prioritization; or worse, there was no actual vision for what the product should be. Management must triage bugs and features; in the absence of doing so, it's totally arbitrary which part of a product is developed, and how much.

One can always claim that the developer should take "ownership," and understand the "whole picture"--that's well and good; but in the absence of some high-level business knowledge, he will still likely succumb to "perfectionism" vis a vis overdeveloping the wrong parts of the product. Otherwise, he should probably be paid to be the CEO (or whomever) in addition to his developer salary.

indeed
Saturday, April 24, 2004

I don't think perfectionism is a very good business practice.

In most business processes, when you're striving for incremental improvements in quality, at some stage you reach a point of diminishing returns. That is - the effort required to improve the quality is greater than the gain achieved from that improvement.

yet another anon
Saturday, April 24, 2004

The more you strive to make something perfect - the longer it will take. Thats why we have patches and upgrades. Plus it gives you the chance to earn more money if you charge ;)

Fothy
Saturday, April 24, 2004

Define.

If you can define perfection without getting into circular logic, you can be perfect and get paid for it. On time. Problem is with the definitions. Get the dictionary straight, and everything falls into place.

By Hoser's definition, there are a _lot_ of *perfect* products. A helluva lot!

KayJay
Saturday, April 24, 2004

"In most business processes, when you're striving for incremental improvements in quality, at some stage you reach a point of diminishing returns. That is - the effort required to improve the quality is greater than the gain achieved from that improvement."

On the other hand, the lack of attention to quality and the common "ship tomorrow" attitude can often cost the company more in the long run than whatever they saved in the short term by skimping on quality. Less products sold, and more time spent bug-fixing to satisfy irate customers instead of being able to work on enhancements that will make money.

T. Norman
Saturday, April 24, 2004

"1. Trying to check in code clean up, sneaking in clean ups when fixing bugs during bug fix for ship cycles."

No manager is going to be happy when a "quick" sneaked fix breaks something else. All fixes must be tracked in case the fix breaks something.

Coward I am!
Saturday, April 24, 2004

T. Norman, you pointed out what I'd call "Not Good Enough" vs. "Good Enough", and for that case what you said is correct.

yet another anon
Saturday, April 24, 2004

It's more of a difference between "good enough for right now" and "good enough". Some managers erroneously think the first is equal to the second.

T. Norman
Saturday, April 24, 2004

It's "prioritization", not "perfection". The trait I look for, aside from technical ability and communications skills, is simply the ability to prioritize.

Nothing is ever perfect. Of those facets of our jobs that demand attention, which should be dealt with first? THAT, my friends, is prioritization. And very few folks I've come across have that ability.

When you have 30 days to ship a product, the developer who can figure out which tasks _must_ be accomplished to ship in 30 days... and spec out the tasks in the right order... is worth his or her weight in gold.

It all comes down to getting working software in the hands of users. Prioritization, IMO, is the key.

dir at badblue com
Sunday, April 25, 2004

In general code that is released to a customer should be 'fit for purpose'. That is, it should do what you claim it should do and what the customer wants it to do.

It should within these bounds be zero defect. You should never release a piece of functionality to a customer that doesnt work within its intended purpose.

Andy Watson
Monday, April 26, 2004

Talking about perfectionism in computer software is like talking about the obesity problem in India.

Yeah no doubt it is a problem somewhere.... but it isn't a problem worth focusing on, in fact, it's the antithesis of the problem worth focusing on.

Aight.

braid_ged
Tuesday, April 27, 2004

Have a look at http://www.yourdon.com/articles/GoodEnuf.html

oh dear another anon
Tuesday, April 27, 2004