I’m restoring some old intel microcomputer kit.

I've got it back together, refreshed the 1702A EPROMS with a home-brew programmer, build a 20mA 100 baud to USB serial interface, but I'm still missing the original paper tape software.

Might it be possible for you to put a notice in your missive, requesting anybody who might have access to said paper tapes or any source code, or further info to get in contact, please?

The born or made question is interesting. I lean very much towards the "born" side, but I think the young engineer still needs some nurturing to develop. By "nurturing", I mean opportunities to develop - not necessarily being handed resources.

For example, my first "opportunites" came when I was about 5 and needed to fix kerosene lamps and fridges and sort out torch batteries etc that my less competent parents could not fathom (artist and lawyer... no hope). Without that our seaside vacations would not have had light and fresh food.

I started playing with crystal sets when I was about 6 - before I could read properly. My first crystal set did not work because I failed to read the text properly and did not understand the need to scratch the enamel coating off the wire to solder it. A few months later I was fiddling with bits of wire, batteries and bulbs and had an epiphany - the enamel was an insulator but could be removed. I went back to my crystal set and it worked!

I think modern educators are under the impression that any children can be dipped in the STEM bucket by making science "exciting". I think this is really a waste of time and money. For the person wired to become an engineer it is already exciting/interesting without the drama. It would be much better to expend the resources on those who show an interest and flair rather than a "no child left behind"
policy.

Real STEM is extremely boring to many people, but is exciting to those that really have the aptitude. Why give those that are not going to make it the wrong impressions?

Watching paint dry might be the idiom of an extremely boring activity, but to an engineer it can be a fascinating experience.

I am still a few years away from retirement (almost 62). I still study and spend at least 10 hours a week just finding out new stuff. I can't see that ever stopping.

"When I hear people promoting STEM for this group of people or that, I shudder.  One can learn the subjects, but being an engineer is much more than that.  It starts inside."

With all due respect to Vlad Z in Muse#481, STEM promotion is needed for many groups for whom the opportunity to express that engineering creativity is denied, either by circumstance, poverty or societal norms.
 It takes a programs like the now common STEM promotion to get those people out of the closet (including out of the closet of their own minds).  If we don't do that, so much talent we really need now will be lost.

"Born or Made?"

Vlad Z's response to an article in your last Muse could have been written by me. I have exactly the same history. I still remember my frustration that the cardboard box/straight pin/rubber band pinball "machines" I made at age 4 or 5 didn't work like I wanted them to. 
 
My buddy Franklin made the mistake of letting me "repair" his wind-up alarm clock when I was 8 or 9. When the repair was complete, the clock's time was exactly correct twice a day and the hands could even still be set. The clock was missing a few parts, however, but I had an impressive collection of gears and intricate (we called such things "delicatessen") parts hanging from my wall.
 
We lived on the Denver University campus, and at one time or another, I explored every room, including the Chancellor's office one day when he wasn't there. The students at the amateur radio club, W0ANA (and my call sign is now WA0ANA in their honor), were especially kind to me and happy to answer my endless questions. When I was 12 my folks bought me a Heathkit communications receiver. I loved constructing it and learned about B+ from it the hard way. One of the guys at the ham shack gave me the parts to build a CW transmitter and I was soon heard on the air as KN0WRN.
 
Years later, at BYU, I bought my first slide rule. I still have it, although until today I think the last time I actually used it was probably 1975. That's when I got my first electronic "scientific" calculator, a TI SR-50, which I also still have.
 
I just used my slide rule to divide 481 by 12. I got a tiny bit over 4. Let's see ... that must be 40. If you've published one Muse per month for 481 months, you've been at it for 40 years! Is that possible? If so, you deserve some kind of award.

Dittos to what Vlad Z said about engineers. His experience echoes mine and  number of engineers with whom I have worked over the years. On the other side of that coin, we had a recent EE grad come to work for us who had decided engineering would be a good income generator, but who had zero prior “engineering/tech” experience – no tech hobbies, no particular interest in electronics, and it showed in his inability to do even simple designs without intense supervision. I believe that he went to work for a local telco, doing some software work.

The rest of the engineering staff all had some level of personal involvement with either electronic or mechanical projects, and had the engineering “mindset” – the “what if we did…” attitude.

I absolutely agree that trying to force/entice people into a career path for which they have no inherent interest will result in less than optimum results.

I just bought two of my favourite books from my childhood off ebay. The “Are Engineers born or made” thread in your last few newsletters prompted me to take a photo and send it in.

The Ladybird book was given to me by my Mum when I was five years old in 1972. It describes basic electric components, magnets, electromagnetism, electroplating and more. It came with me everywhere and I read it cover to cover hundreds of times.

A friend at school put me onto the Usborne book in grade 4 at school. That would have been 1976. I borrowed that book over and over and finally I saved up and bought a copy for myself. It had heaps of great stuff to build and obviously covered much of the same stuff as the Ladybird book.

I did most of the experiments from both books. Mum bought me the book as I always pulled every battery operated toy I had apart within hours of receiving it. I was always after the lightbulbs and motors so I could make my own cool stuff.

I would have to say that engineers are born. For me, I was definitely made better at engineering by caring people. By Mum, and by my teacher Mr Prindable in grade 7 who both listened to me and encouraged me.

The books are in front of my Agilent E4422B RF SigGen.

Note that "a function is fully tested" is relative. In the DO-178C context you mentioned, what "fully tested" means is dependent to the assessed hazardous effects of error, moreover, "fully tested", here, also means the degree of coverage of correctness of outputs with respect to requirements only.

Yes, v(G) gives a "minimum number of tests one must run in order to insure" a degree of coverage, that particular degree of coverage being Branch Coverage. 

Please note that with respect to source code, Branch Coverage is not exactly the Decision Coverage that DO-178C requires. This has been recent for us to learn.  Decision Coverage requires covering both true and false results of all Boolean expressions, not just those in control of structural branch statements [Rierson, 2013]: 

• “Decision – A Boolean expression composed of conditions and zero or more Boolean operators. If a condition appears more than once in a decision, each occurrence is a distinct condition.”
• “Decision coverage – Every point of entry and exit in the program has been invoked at least once and every decision in the program has taken on all possible outcomes at least once.”

Note also that depending on the definition of Path Coverage, Path Coverage is not same as Branch Coverage; some use Path Coverage and Branch Coverage synonymously,  but a common definition of Path Coverage is that ever combination of branches is followed.

Your three paths do accomplish Branch Coverage, but there is one more unique path that could be taken, 1-3-4-5-6-7. RTCA determined that exhaustive Path Coverage of this sort was excessive for even Level A, but I can imagine that if you ran only 3 out of four paths on arbitrary code, you might miss an erroneous output, especially with C shenanigans.

And a final word about automated test generation where the tool generates test cases based on the tool's analysis of the code instead of requirements. Automated test generation from source code is just as doomed to succeed as the manual kind.  

Also, a comment on testing...

You might have seen the various discussions on branchless programming.
This is where code is rewritten with the goal of reducing branches (ie. reducing or eliminating if then else and similar constructs).

The main reason to do this is reduce branching costs on highly pipelined processors. A CPU pipeline has multiple instructions in overlapping stages of execution. If a branch occurs then typically the pipeline needs to be flushed and a lot of work is thrown away.

Considering there are CPUs with over 30 pipeline stages, there is some value in getting this right.

Various CPUs take steps like branch prediction to reduce the costs, but clearly a branch that is not there is better than a branch that is there. Hence the motivation for branchless processing.

For example we can replace

if (a < b)
   greater = b;
 else
   greater = a;

with the branchless version:

greater = (a < b) * b + (a >= b) * a;

It seems to me that would reduce the cyclomatic complexity too.

I do have some reservations about cyclomatic complexity though. I think that in complexity terms there is no real difference between these two examples. ie. trivial selection cases that are exhaustive should not drive up complexity scores.

It would be interesting (well to me anyway)  to see what others think.

I agree that more testing and more measuring would be better, but wouldn't it always be so? I think you shipped an important disclaimer, as relying on tools for testing can go wrong.

Maybe we should tell software engineers that they do not need do testing, as their managers will do it:

A colleague of mine used cyclomatic complexity to evaluate the quality of software that others created for him. He needed to only look at the functions with a high cyclomatic complexity rating to find the worst parts of the code. Those were also usually the spot where the bugs were hiding.

An external appraiser told us that he evaluates a code base by linting it. He starts with no rules disabled and then looks at the issues that are reported the most. In the beginning these are usually harmless things where the style guide deviated from the lint defaults. He then disables this category of issues and repeats. And this leads him to the real issues of the code base.

But I disagree on the tools to automatically create tests. Automatic tests can only find some kinds of issues. And a tool that creates thousands of test then can eliminate some classes of errors. But if this then leads to a 100% code coverage target. What in such scenarios always means only line coverage. What then leads to the removal of dead code, then I get a very bad feeling. You might end up with a code base that is worse than before. It now spends  a lot of time on range checking values that have been range checked before and even though the team is convinced that they now have the best software ever they still run into bugs. Maybe even more than before, but definitely different issues than before. Which might mean harder to find issues.

What those tools can not do is think about what the result of the tests should be. What is the best thing to do in an edge case can be a different question. If some values or behaviors make even sense is something that the tool can not decide.

For the best bang for the buck I would suggest to do static analysis(lint, cyclomatic complexity,..) and to then look into the code where the static analysis is unhappy. And to add tests to the complex functions. Also add descriptions to the test that explain the use case.

It is an often forgotten reality that test break. When working with a code base sooner or later test will break. Automatically generated
(stupid) test break the first and they will probably just be removed.
Having a good documented test on the other side could be the equivalent of the senior engineer saying "Oh if you change this, how will it work when ..." If one has a good answer to that then the test can be changed, otherwise one might realize that the test is correct and the code needs more love.

Doing something without thinking can be better than not doing anything.
It can also be dangerous and thinking and then doing is always better.