Has anyone ever released a major build of software that was perfect?

[minestrone]

I have not and I think I have had enough chances to.

[Zippy]

Short answer - no.

[TimberWolf]

No one has even come up with a method to decide whether software is even perfect. Although a British chap did say the task was in general quite impossible to determine. He also said it might loop forever for all you know, but didn't mention fonts as far as I recall.

[minestrone]

No one has even come up with a method to decide whether software is even perfect. Although a British chap did say the task was in general quite impossible to determine. He also said it might loop forever for all you know, but didn't mention fonts as far as I recall.

It is a wonder message boards get by with conversation stoppers like yourself.

[Gonzo]

I don't think perfect software is achievable unless it's functions are pretty limited and straightforward.

Back in the days I worked on software everyone was happy provided that the known issues list had everything on it and the clients did not raise any surprises.

I have worked with one PM on change projects who always insisted that go live would be on the original go live date whatever the state of the delivery and everything that still needed to be fixed at that point would go on an issue log which would then be worked through. He was PWC trained.

[threaded]

When I get something working for a client they're often so happy and effusive they'll say that it is perfect. There again, they've generally been Bobbed, so the application just starting up is enough to cause them tears of joy.

[NickFitz]

Back around 1983 a friend of mine wrote the software for the Teletext flight display system at Dublin airport. It ran 24/7/52 for at least five years. Of course, it may have had bugs that just didn't get triggered during its lifetime.

On the other hand, I once shipped an Amiga game to Ubisoft's bug testers. I'd been working on that thing day in, day out, for months; I knew it inside out. Within eighteen hours, they'd sent over two A4 pages of one-line bug reports in poor English (they were French teenagers who'd skipped college because they got paid for playing games all day), including one bug I was sure I'd squashed months before. Turned out I was setting a flag one instruction after grabbing a pointer (this was all in 68000 assembler) rather than just before and thus conflicting with an interrupt handler that did shedloads of stuff behind the main thread (in some ways, the interrupt handler was the main thread) - yet that bug never manifested when I was playing it.

Of course, I realised that I subconsciously knew how to avoid triggering it, and indeed, I had that down pat; once I consciously knew it was still there, I was (to my surprise) able to flip that ability on its head and trigger it every time the random event generator produced a certain state at just the right concatenation of circumstances, which was almost every time (it was a very deterministic state transition corresponding to a specific player action in a specific context).

Sometimes our minds allow us to play tricks on ourselves, but when we know what it's up to we can make use of those tricks - turning that one on its head saved me hours of debugging, as I was able to diagnose and fix the bug in about twenty minutes

It also had that sense of certainty about it. I've found over the years that, as with that one, you can fix a bug, yet somewhere in the back of your mind you keep suspecting it will come back and bite you. This means you may have fixed a lot of the bug - you've eradicated most of the circumstances that will result in it happening - but you know, deep down, that you haven't fixed the root bug. Once it does come back and you find the true cause, rather than all those other peripheral triggers of the true cause, you know for sure that you've eradicated that bug once and for all. If you don't feel that... well, then you haven't found the true cause, and it'll be back

[cojak]

In the very old days, when I was a newb programmer I used to find that a symptom fix in turn became a bug as I came close to sorting out the root cause...

I used to find that I was the cause of most of the bugs in my code.

I was a rubbish development coder but because of my experience a pretty good trouble shooter/bug fixer of established code. (I subsequently discovered my talent at spotting patterns..)

Of course I don't code at all these days...

[BlasterBates]

Well the company I was built the Software for the runway lighting at one of the biggest airports in Europe.

They applied real QA, like with huge knobs on and used the then "modern" Yourdon analysis and design technique, with analysis and design tools.

Hardly any real code was written, it was all generated from the design tool.

When it was installed on the date they'd planned 2 years earlier. it worked first time and no errors were ever reported.

I wasn't involved on the project, but I was somewhat impressed.

[suityou01]

Wrote a database migration (50 tables or so) that ran first time, no errors, 100% effective. Mind you that was the brief, it had to be run before year end, and I delivered late, right down to the wire. The thing was I wasn't prepared to release it with bugs, so they got it when I was good and ready.

I reckon deadline pressure creates the most bugs.

HTH