ID:1568987
 
Keywords: finished
Anything you make must have flaws otherwise it will never be finished.

Do you agree with this stament? Why or why not? How many flaws is your finished project allowed to have.
Well, the question(s) are pretty flawed, if you'll forgive the pun.

Perfection is essentially an ideal or theoretical, and to a great extent in software in particular, subjective. Perfect circles are for instance are a construct of theory, a very useful one of course when working within mathematics and engineering, but a construct of theory all the same.

Now, the original proposition is such:

"Anything you make must have flaws otherwise it will never be finished."

And is essentially sound. Flawlessness, perfection, is a theory, an ideal, a thing you tend towards in a practical setting, but never reach by it's definition. So given infinite time, and infinite resource, you may reach perfect software. However the software similarly won't be "finished" until you've reached the end of that. And well, infinite in this context is "unbounded", limitless, has no end.

The stuff of theory. Over in the real world, I'm gonna die at a finite point, and have finite resource. So I can't make flawless software, simple as that.

The follow up question is where we start to have issues:

"How many flaws is your finished project allowed to have?"

12.

...
...
...
...

I'm messing, it's potentially infinite.

A better (just about) question is "How many known flaws is your finished project allowed to have?"

10.

...
...
...

Again, I'm messing. As many as it likes, provided they don't detract from the core functionality of the project. So again I guess, potentially infinite.

The flaw is "how many". Software quality management (like any quality management) uses numerical assessment to assist in providing a picture, to help a guided gut feeling decision. It doesn't provide (unless you're not very good at quality management I suppose) a mechanical process for gating releases.

This is why release management, even in continuous deployment, doesn't just release software if they have less than X many bug reports open. Because even one of those X many could be seriously functional bugs, that render the software practically useless.

You need the qualitative assessment (being quality management) to decide if the flaws are a big enough problem to prevent you calling the product done. I could have 1000+ open bug reports, but if they're all things I and the common use-cases of the system couldn't care less about, they aren't relevant bug reports in determining release quality. (Ideally I'd mark these "won't fix" to aid my bug tracking, but that's another talk)

I would've thought this was obvious? But maybe not?
Yay, Quizalot is back! I thought you were done asking us questions.

I assumed that people generally released a product after they removed all bugs they were aware of. And then patch anything else they come across afterwards. That's what I do, at least.

I don't think anyone makes a game or software and says "Ok, we have 30 bugs to fix, however, we're going to release it once we knock out 10 of them, because 20 is an acceptable number." Well, maybe Microsoft does. Don't be like Microsoft.
Well, in bigger software in general, you tend to have known bugs when releasing. But they are not necessarily things people care about. Case in point, the system I'm on at work has 150 open bug reports, the customer that is running the software live cares about none of them though, so they took the release and use it.

In games, you don't really get to chat to your customer and go "This bit's kinda buggy, but that's okay, right?" first, so yes, you probably fix everything you are aware of at the time.
Typically if a bug wouldn't bother the player, it goes on the bottom or doesn't make my to-do list at all. I was referring to like, if you had 30 game or software-breaking bugs.

For example, the hospital I used to work at released software updates that were buggy and at some points unstable, but it was still usable for the most part. So even though patients would sometimes get randomly logged out of their accounts while trying to access their medical records, ultimately just relogging and attempting it a second time usually sufficed and so the bugs exist but are not severe enough to where the patient can't do anything with it at all.

Which was funny though because from what I saw, they had a pretty rigorous QA process. They would take a small patch and test it for like 2 or 3 days and when it released it would still be a mess.
False. I use every kind of pesticide there is. My work has no bugs.
In response to EmpirezTeam
The bit about QA is pretty much my life, at the moment. What our QA guys actually do with all their time is a mystery to me.
In response to Stephen001