Re: Larkin, Hobbs let's meet in the middle.

On Sun, 03 Aug 2008 17:03:37 GMT, Jan Panteltje
<pNaonStpealmtje@xxxxxxxxx> wrote:

Writing software, well most of you know MS, one fix after the other,
never bug free.
I must say if John Larking gets th code right 100% bug free before
he releases whatever it is, then my hat of to him!

100% right most of the time. Not 100% right 100% of the time.

The thing I'm about to release has 431 distinct serial commands to
parse and execute, most with arguments. It would be nice if every one
does exactly what it's documented to do.



But who is the judge? Do you run soft to evaluate, do you
have testers, or is it yourself.

Both. I test my own stuff, and ask others to test it, too. I have a
guy writing a Java-based virtual instrument to talk to this box, so
he'll verify most everything too.


In the last case there are some question marks.

It is a tricky thing, some weeks ago I got a bug report for a
z80 disassembler I wrote in the late eighties or nineties...
Fixed it and released a new version.

As to the hardware, now after so many years I get it right first time,
but still you can think of small improvements that could be in a next version.

Sure. That's good too.

In the early days I got it wrong a couple of times really badly...

I don't want to remember.

But I have seen so many revision PCBs, so many PCBs with wires, done
by people who claimed they were really good, almost have to laugh.


I saw the first LSI-11 board at DEC. It looked like a red bear pelt on
both sides. It worked.



I guess it bytes you more if you make a mistake in something that will be made a
million times, then in a one of piece of scientific equipment that
can be easily updated.

But I have learned to test circuits a little bit at the time, before
using them in a bigger design.

Now, these days, with simulation it may be easier to have a look at what will happen,
but th soldering iron rules in the end.
The simulations are really good though, but the scope rules.

So, guys, somewhere in between the extreme viewpoints of 'first time perfect'
and 'many versions before it is right' is a reality - the reality
that we are neural nets that often, but not always give the correct
answer to the question-.

Even endlessly trained operators of nuclear reactors in submarines make mistakes.
Everybody makes mistakes.

Yes. But accepting iteration and failure is self-fulfilling. With
care, most hardware can be right the first time, and most software can
be done on time, bug-free. It's a habit, or not.




So... OK Phil, I agree, after claims of perfection we should let others check too ;-)




I program embedded stuff in assembly, which is more likely to
obviously be broken when something's wrong. Higher-level stuff can
have problems in libraries, memory leaks, deadlocks, mysterious hangs,
stuff like that.

And I *read* my code to debug it, before and after it's actually run.
I think that's the best way to generate solid code: read, comment,
rewrite, clarify, eliminate risk. Hack-and-test-and-iterate is the
path to bugs, in hardware or software.

This theory may be interesting: The easier it is to modify a design,
the less care the author will put into the initial version, and the
more bugs will be shipped. Consider

The Space Shuttle (first liftoff was manned, to orbit)
Bridges
Airplanes
Skyscrapers
....
Pacemakers
ASIC design
Hardware (pcb) design
FPGA design
Software

See? If somebody figures that bugs are inevitable but they're easy to
fix, they'll hack-and-debug. And they won't find all the bugs, because
they won't really care, and won't have the time anyhow.

I'm reading Showstopper!, the story of the development of NT. I think
somebody here recommended it.

"Indeed, Cutler had found a calling in life. 'What I really wanted to
do was work on computers, not apply them to problems.'"

I think there were thousands of NT builds.

Sound familiar?

John


.

Relevant Pages

  • Re: Softwares evil
    ... as hardware design more and more resembles ... you inevitably get more of late delivery, bugs and misinterpreted specs. ...
    (comp.arch.embedded)
  • Re: Softwares evil
    ... as hardware design more and more resembles ... you inevitably get more of late delivery, bugs and misinterpreted specs. ...
    (comp.arch.embedded)
  • Re: relative complexity of hardware and software (was: pick n place machines
    ... systems seldom have bugs. ... But most software has bugs. ... I don't design hardware logic so I'm just guessing. ... programmable logic does indeed allow for ratshit programming. ...
    (sci.electronics.design)
  • Re: OO Software Project Entropy Question.
    ... > the project may tend to spend more and more time fixing bugs. ... If a team implements features in small batches, such as 5 features a week, ... There are those who decide that "refactoring" is re-work. ... Design Smells are errors in design - not bugs. ...
    (comp.object)
  • Re: Is shared memory a total mess or am I just being thick????
    ... the more opportunities for new bugs you create. ... of Ingres that need improvement, ... if there are no problems, i.e. if it ain't broke, then don't fix it. ... Now whether "the approach is sound to begin with" is a question of design ...
    (comp.databases.ingres)