It's Always the Software

"Like it or not, all software contains bugs."

Mr. Steve Gibson writes BUG FREE software in machine language.

BUG FREE SOFTWARE

Too bad Microsoft didn't start off that way and stick with it.

How do you ensure that the software you deliver or purchase performs as advertised?

Don't use Microsoft?

You take a page from the global warming nuts and everyone else who bows down to computer results. If the program give you what you want to see, then it is working correctly. If not, hide or throw away results and maybe the program to boot.

"One brand" assume no liability for damages consequent to the use of this product. ... However, no responsibilities assumed by "one brand" for its use, nor for any infringementsof patents or other rights of third parties resulting from its use..." It is sceleton quotation from license agreement no matter what a brand (btw quite good one). It's one of reason that software market players having kept its tradition to avoid any responsibility for any consequences. We end users(engineers) have to response for all.

So to change legal practice for sharing some responsibilty with soft makers is one of ways to improve quality of software. But I do not think it's the main though it's so important.

Second --- do not allow the situation of any kind of monopoly on market. It's the only factor what I assume are keeping software on somewhat appropriate level concerning its quality and reliability.

It's known facts when some of car-makers had made voluntary resigns of wrongworking vehicles. I suppose they did it being scared to lose their customers.

I do agree with Del the cat about impossibility to make absolutely bugfree software as it's impossible to build absolutely reliable bridge or plane. But other branches of industry have very long history to compare with IT. So we can only hope that IT market will find its balance between legal and competetive market issues.

I do not know what there been presumed under that blog entry for engineers, but I think it is complex problem and clue is lying far beyond only engineering competence.

"How do you ensure that the software you deliver or purchase performs as advertised?"

Since I don't deliver, only purchase, I rely on test results from journals/magazines or Consumer Reports (I seldom need to be first-year cutting edge), and get what comes closest to working.

"How and where in the cycle do you test it?"

Immediately after installation.

"How do you fix the problems you find?"

If at work, I call our tame IT professional. If at home I call the help desk, and hope for the best in either case.

"How do you respond to software's performance personality quirks?"

On a good day, with a grin and a shrug. On a great day, with a 9mm attitude adjustment tool from Beretta. A hardware solution to a software problem...

Software should be tested along the way, not only after the whole thing is finished.

I test every subroutine when I finish with it. Its a lot easier to catch the bug early and when you still remember what you have programmed. After 2 days, you'll not have a clue what you've done.

How do you ensure that the software you deliver or purchase performs as advertised? -- as long as you use it as advertised or instructed. If you perform a job or sequence that deviates from the instructions, the guarantee is void. A good software programmer, however, will take complaints from misuse and make a fix to either prevent the user from doing it again or to allow the program to accept the user's method.

How and where in the cycle do you test it? -- while you're creating the program, when you finish the program (final test), and for the lifetime of the program.

How do you fix the problems you find? -- with all the skills and knowledge I possess.

How do you respond to software's performance personality quirks? -- I've never encountered a program with a personality . When I find a problem, I get down and fix it. What else do I need to do?

I'm sure you're referring to computer programs. I haven't delved into these things in decades. Back then, I was using the Z80. I also programmed using BASIC. A thorough knowledge of what the program is expected to do is really important. Today I deal with PLCs. There's not much difference, however, in my opinion.

Most of the time, I determined how the program runs and interfaces with the user. The user either conformed or he will have problems using it. Today, however, I sit down with the users and ask them what they want. Most times, they know what they want. Sometimes they're not sure, which can be quite frustrating.

Here's a bug I have at work.

Rather an old bug as you can see from the style of disc he carries (he's taken a big byte from it) My Daughter made him when she was about 10...