PDA

View Full Version : Has anyone ever released a major build of software that was perfect?



minestrone
21st April 2010, 20:36
I have not and I think I have had enough chances to.

Zippy
21st April 2010, 20:47
Short answer - no.

TimberWolf
21st April 2010, 21:11
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
21st April 2010, 21:20
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
21st April 2010, 23:40
:rollin:

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
22nd April 2010, 03:52
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. :D

NickFitz
22nd April 2010, 04:43
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 :freaky:

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 :ohwell

cojak
22nd April 2010, 07:06
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. :freaky:

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

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

BlasterBates
22nd April 2010, 08:05
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
22nd April 2010, 08:15
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

Mich the Tester
22nd April 2010, 09:34
:rollin:

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

Even then it would have to be running on a perfect OS on a perfect machine.

JimBobTwoTeeth
22nd April 2010, 09:41
It's near impossible for a group of BAs to think of every permutation that a large user group will.

It's near impossible for a group of SAs to think of every permutation that a large user group will.

It's near impossible for a group of Developers to think of every permutation that a large user group will.

It's near impossible for a group of testers to simulate every permutation that a large user group will.

Hence bugs.

Mich the Tester
22nd April 2010, 09:45
It's near impossible for a group of BAs to think of every permutation that a large user group will.

It's near impossible for a group of SAs to think of every permutation that a large user group will.

It's near impossible for a group of Developers to think of every permutation that a large user group will.

It's near impossible for a group of testers to simulate every permutation that a large user group will.

Hence bugs.
whs

It sometimes leads to interesting (actually rather tiresome) discussions after a system has been tested and then users are faced with issues. One of the things I always try to do when taking on a testing project is to manage the expectations of the clientco. Some clients think that if software is tested there is no possible excuse for bugs being found in production. I try to explain to them beforehand that testing can never prove the absence of bugs, but can only demonstrate the presence of those bugs that can be found using the test cases that are prepared, and that the accuracy of any statement about a system’s quality is related to the specific configuration of software and hardware on which it is tested. Testing is also a time and budget constrained activity, just like development or analysis; give us 2000 years, an unlimited budget and a frozen configuration and we might be able to test every possible path through a very simple piece of software that automatically sends cards to people their birthday. Still, we can’t guarantee the OS or the hardware config.

One loud American CFO once threatened me and his software supplier with legal action if any bugs at all were found after taking a system into production. Both the project manager and I then told him that he had two options;
- never take the system into production, or
- accept our resignation immediately
He then took advice from his legal staff and came back with a more reasonable proposal and a somewhat grumpy look on his face.

Spacecadet
22nd April 2010, 09:45
They're not bugs, they're features! :tantrum:

JimBobTwoTeeth
22nd April 2010, 09:52
whs

It sometimes leads to interesting (actually rather tiresome) discussions after a system has been tested and then users are faced with issues. One of the things I always try to do when taking on a testing project is to manage the expectations of the clientco. Some clients think that if software is tested there is no possible excuse for bugs being found in production. I try to explain to them beforehand that testing can never prove the absence of bugs, but can only demonstrate the presence of those bugs that can be found using the test cases that are prepared, and that the accuracy of any statement about a system’s quality is related to the specific configuration of software and hardware on which it is tested. Testing is also a time and budget constrained activity, just like development or analysis; give us 2000 years, an unlimited budget and a frozen configuration and we might be able to test every possible path through a very simple piece of software that automatically sends cards to people their birthday. Still, we can’t guarantee the OS or the hardware config.

One loud American CFO once threatened me and his software supplier with legal action if any bugs at all were found after taking a system into production. Both the project manager and I then told him that he had two options;
- never take the system into production, or
- accept our resignation immediately
He then took advice from his legal staff and came back with a more reasonable proposal and a somewhat grumpy look on his face.

I always make the point that the Business Requirements are IT's contract with the business. Anything that contravenes these is a bug.

Of course it helps to have good BAs who leave no ambiguity in the BRD. So a QA team should always test the docs before the system.

Mich the Tester
22nd April 2010, 10:02
I always make the point that the Business Requirements are IT's contract with the business. Anything that contravenes these is a bug.

Of course it helps to have good BAs who leave no ambiguity in the BRD. So a QA team should always test the docs before the system.Another aspect I notice at clientcos is the attempt to save money on testing by getting the users to test a raw, freshly delivered system before a professional tester has seen it. The big risk here is to expose users to all the teething problems and damage their confidence and motivation before the system has even been rolled out. One big advantage of professional testers is they don’t get upset about finding bugs; they (should, if they’re real testers) enjoy it and are happy to do it every day. What testers cannot do is guarantee a system to take into production, however given time and resources and functional information they can help you to present a system to users that stands a reasonable chance of acceptance and doesn’t scare your users into mass rebellion, as some systems have done at clientcos. Unfortunately, by the time someone like me gets hired in it’s usually too late and the users have already been exposed to tulipware with all the concerns that brings for them. Having said that, if I’m honest those are really the situations in which I thrive, and when given a project from the start I sometimes get a little bored. 'Crisis management' tends to pay well too.

VectraMan
22nd April 2010, 10:27
All my software does exactly what I told it to do, so by that measure is perfect.

Whether I programmed it to do the right thing or not is a different issue. It's not its fault that I'm not perfect.

Scary
22nd April 2010, 11:03
Everything that comes out of Cupertino is perfect. :rolleyes:

If you want to prove that your software is perfect, you could always try specifying it in Z. :rolleyes:

TimberWolf
22nd April 2010, 11:12
The most common way of getting your software perfect, is to define it as perfect, regardless of how borked it is. Sorted.

VectraMan
22nd April 2010, 11:16
If you want to prove that your software is perfect, you could always try specifying it in Z. :rolleyes:

Thanks for that. I've gone years without thinking about Z, and now you've gone and reminded me of it.:tantrum:

original PM
22nd April 2010, 12:20
They're not bugs, they're features! :tantrum:

I agree all my software releases have been perfect just with some additional features!

Although why is it that no matter how many test cases you have the users will always manage to use the system in such an obscure way that it throws up a bug/system feature!

Paddy
22nd April 2010, 13:11
I have not and I think I have had enough chances to.

Yes, Edlin.exe

kaiser78
22nd April 2010, 17:54
I will this weekend when my project goes live...fingers crossed and wish me luck...