USB network analyzers -- as bad as USB oscilloscopes, or not?

[hendorog]

Software should be bug free as delivered.

That one will hit a nerve with any serious software developer. It is well known that it is impossible to develop bug free software.
This isn't some attitude, its impossible.
Therefore, accepting that everything ships with both known and unknown bugs, the hardest decision is simply deciding when to ship.

[dadler]

As we say in my line of work:

"No code has no bugs."

And both meanings are fully intended.

[rs20]

As we say in my line of work:

"No code has no bugs."

And both meanings are fully intended.

I disagree with one meaning: processor-free ("no-code") designs can absolutely have bugs.

[Wuerstchenhund]

Software should be bug free as delivered.

That one will hit a nerve with any serious software developer. It is well known that it is impossible to develop bug free software.
This isn't some attitude, its impossible.
Therefore, accepting that everything ships with both known and unknown bugs, the hardest decision is simply deciding when to ship.

Indeed. Software should ship in a state where all functionality that it has been marketed with work as advertized, and where the core functionality doesn't exhibit any major show-stopping bugs.

Bugs per se aren't a problem, the problem is when what at best is beta software is shipped where major parts of the functionality are broken.

[Rupunzell]

Software must out their nose to the keyboard and screen and work until the software is bug free. This has been done and can be done if honest effort is put forth and stated design requirements DO NOT CHANGE.

Software developers must write, test, verify their software-firmware as if their life depended on it. Management must understand why this makes a difference for users and why it is of such importance. Profits should be put secondary to customer-user experience as this builds brand identity and user-customer confidence in their product.

It's that simple, anything less is not acceptable.


Bernice


[/quote]
That one will hit a nerve with any serious software developer. It is well known that it is impossible to develop bug free software.
This isn't some attitude, its impossible.
Therefore, accepting that everything ships with both known and unknown bugs, the hardest decision is simply deciding when to ship.
[/quote]

[Wuerstchenhund]

Software must out their nose to the keyboard and screen and work until the software is bug free. This has been done and can be done if honest effort is put forth and stated design requirements DO NOT CHANGE.

That is BS. Software can't be completely bug free, that's a simple fact. The main reason is that software is impossible to test for every possible scenario. The only thing one can do is to test for a sufficient number or cases so that the worst bugs can be eliminated.

Even the software you believe is bug free has bugs. Just because you don't see them doesn't mean there aren't any.

Even highly safety-critical software has bugs.

Software developers must write, test, verify their software-firmware as if their life depended on it. Management must understand why this makes a difference for users and why it is of such importance. Profits should be put secondary to customer-user experience as this builds brand identity and user-customer confidence in their product.

Again, software can't be completely bug free. All you can do is to eliminate the worst one (especially show stoppers) so to reduce the likelihood of the user experiencing one, but you can't eliminate it. In general, the costs of fixing them also increase exponentially with the number of bugs solved, which means at some point it's just not worth fixing any more.

It's that simple, anything less is not acceptable.

It's that simple only in the mind of someone who hasn't written any even only moderately complex piece of software, or done software testing for a living. But just because you believe it's that easy doesn't mean it conforms with reality.

[Rupunzell]

Increasing complexity often results in non-linear increase of possible problems.

This is why reducing complexity as much as possible to directly address a problem for a given result works.


More is often not better.
Bernice

[joeqsmith]

We looked at Copper Mountain last summer.     

https://www.coppermountaintech.com/

What'd you think?

We were looking to replace our HP8753s after we hand another unit fail.   I personally did not evaluate the system but spoke with the person who did.   They were very impressed with it.   There was a spur they found that was caused internally of the unit that they were surprised we found.   It was not a concern to us in what we would use them for.     

[hendorog]

Bugs per se aren't a problem, the problem is when what at best is beta software is shipped where major parts of the functionality are broken.

Yep, this is the hard part about deciding when to ship - pressures build up for non-technical reasons and often poor decisions are made by non-technical management operating with imperfect information. Organisations with better processes are better at it.

Increasing complexity often results in non-linear increase of possible problems.

It _always_ does! Unfortunately the productivity hit from discarding the OS, discarding any libraries, discarding any COTS hardware/CPU's and designing it all from scratch to precisely fit the minimum viable set of requirements is too severe. The scopes which are based on Windows or Linux or xyz OS mean that a heap of stuff arrives for free and doesn't need to be built.

The reality is that every line of code written makes assumptions. The human brain can't cope with the level of complexity required to know every possible interaction at every level from the hardware up to the application. Because of that testing is needed as a _fallback_, and anyone who knows testing should know that you can't test in quality.

This is an interesting writeup about the extreme end of software: http://www.fastcompany.com/28121/they-write-right-stuff

quote:
"It's like pre-Sumerian civilization," says Brad Cox, who wrote the software for Steve Jobs NeXT computer and is a professor at George Mason University. "The way we build software is in the hunter-gatherer stage."

[tggzzz]

Increasing complexity often results in non-linear increase of possible problems.

It _always_ does! Unfortunately the productivity hit from discarding the OS, discarding any libraries, discarding any COTS hardware/CPU's and designing it all from scratch to precisely fit the minimum viable set of requirements is too severe. The scopes which are based on Windows or Linux or xyz OS mean that a heap of stuff arrives for free and doesn't need to be built.

Just so. Many people have forgotten than both HP and Tek used to ship test equipment based on Smalltalk (Windoze more-or-less didn't exist then)

[KE5FX]

Software developers must write, test, verify their software-firmware as if their life depended on it.

That can be done, and in some industries it is done.  But I don't think you're going to like the price tag.

[hendorog]

That can be done, and in some industries it is done.  But I don't think you're going to like the price tag.

Dead right. Not to mention that while spending all that time and (someone elses) money on super high quality work, technology, or the market shifts and makes your product irrelevant.

[pascal_sweden]

Back in the old days, they used to have 2 test engineers for every software engineer.
I think they now have 1 test engineer for every 10 software engineers.

Is this a natural evolution of Scrum, Agile Software Development, and Lean Startups?
What happened to Digital Six Sigma? 3.4 defective features / million opportunities

Common jokes among engineers:

"It's not a bug, It's a feature"

"We could do better, but have you seen our competitors? We suck the least"

"It's not a hardware issue. It's a software bug. No, it's not a software bug. It's a hardware issue"
"Or maybe it's the firmware?"

[hendorog]

Is this a natural evolution of Scrum, Agile Software Development, and Lean Startups?
What happened to Digital Six Sigma? 3.4 defective features / million opportunities

If you can spare a few bucks, this book is a very clever parody of what life is like in the seriously dysfunctional corporate IT world:

http://www.amazon.com/The-Phoenix-Project-Helping-Business-ebook/dp/B00AZRBLHO

There is some really good clever stuff in there taken from the Toyota/six-sigma/TQM world and how it can be applied to modern software development and IT.

At my last job we were all asked to read it, and it actually really helped us break down some corporate silos and get people working together as a team. The same principles apply to product development - hardware vs software vs firmware vs project management.

The batch sizing/queuing theory stuff and Kanban is really interesting too - there is a board game (I think it was this one http://getkanban.com/ ) which really demonstrates how getting control of processes can pay off in throughput and productivity.

It was also fun putting names of your colleagues to the characters in that book

[Bud]

@KE5FX

Sorry to steer off topic but since you are here- are you the author of 7470 ? If so can you tell if the GPIB adapter from the other thread work with your software ? (may be you could throw a line there)

https://www.eevblog.com/forum/testgear/flood-of-new-agilent-82357b-gpib-usb-adaptors-on-ebay-the-real-deal/

[KE5FX]

@KE5FX

Sorry to steer off topic but since you are here- are you the author of 7470 ? If so can you tell if the GPIB adapter from the other thread work with your software ? (may be you could throw a line there)

https://www.eevblog.com/forum/testgear/flood-of-new-agilent-82357b-gpib-usb-adaptors-on-ebay-the-real-deal/

Yes, that's me, and I actually just bought 3 of those for a $100/each best offer.  Assuming they are the real deal, they should work OK with most of the toolkit apps after you enable NI488.2 compatibility in the Agilent config utility.

I'm going to try to support them natively to dispense with that step.

[Bud]

Thank you very much Sir and good to have you on the Forum.

[G0HZU]

When I need SFDR, nothing beats the old-school HP iron... but hey, I also can't get a 40 MHz realtime data stream out of my 8566B, so it's horses for courses.  The RSA306 and its competition from Signal Hound are really nifty gadgets.

Yes, the RSA306 offers some neat RTSA capabilities over a wide BW Note that for some tests of SFDR (eg IP3 vs DANL) I found the little RSA306 gave similar performance to an HP8566B. I didn't have enough time to do lots of testing for this so I just did a few classic checks. So in some areas it performed quite well considering its SWaP limitations. But the HP8566B has a fairly weak first mixer on its 0-2500MHz range and it's the only (classic) high performance lab analyser we never ever bought or rented at work because of this. It was very expensive too!

For the frequency bands we were covering back then there were better choices when looking for decent IP3 and 2HI performance. eg the HP8568B and especially the TR4172 from Advantest which easily outclassed them both here with its 8 diode first mixer and +22dBm LO drive level