Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
 Issue Number 449, July 5, 2022
Copyright 2022 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com
   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

Contents
Editor's Notes

SEGGER Embedded Studio cross platform IDE

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.
Quotes and Thoughts

If you can't write it down in English, you can't code it.
Tools and Tips

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.
Freebies and Discounts

The giveaway is on holiday for the summer.
More on Testing

I wrote about the limits of complexity testing in the last issue. John Carter responded:

In the embedded world we will _always_ be pushed to make do with less. Lower power consumption, lower unit price, smaller mechanical form factor....

Thus we tend to favour static analysis or off target dynamic instrumentation like valgrind. (ps: If you're using C/C++ and not using valgrind, stop reading this and wire it into all your unit tests NOW!)

A year or so back I added gcc's -fsanitize=bounds -fsanitize-trap to our build.

The performance impact has been minimal, but has caught a steady trickle of silly little index out of bounds bugs for us, that would have been really hard to catch otherwise.

ps: If your platform has enough grunt, like an arm Linux type thing, you can run valgrind there too! Just has a fairly high performance impact.

Complexity:

Yup, this is my pet bug bear.

"At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way — and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay. C. A. R. Hoare"

The best test tool  for exploring complexity is Fuzz Testing, which is "unreasonably successful".

  1. Bug's exist where the reality of the code deviates from our mental model. And since we humans always have one (no matter how vague or wrong), we always have blind spots.
  2. Fuzz Testing cares nothing for anything except exploring an ever larger space of possibilities.
  3. Creating a good oracle for fuzz testing is hard, but even with weak oracles like "it shouldn't crash" it's unreasonably effective.
  4. Fuzz testing is an art, choosing good targets,  navigating bottle necks like checksums requires thought.

There is a very steady stream of Academic papers on wonderful advances that never make it into industry. The best "industry ready" fuzz testers seem to be afl++ and clang's libfuzzer.

Fuzz testing is not new. Fifty years ago we tested compilers by scavenging random stacks of punched cards from the trash and feeding those decks as source files to see if the tool would crash. In my opinion such testing is useful but is just an adjunct to necessary tests against the requirements.

"Program testing can be used to show the presence of bugs, but never to show their absence!" Edsger W. Dijkstra

Clyde Shappee wrote:

I really liked Zack B's remarks about code cruft and reworking or refactoring the code.  This is really important (says a hardware guy).

I worked at a company where the entire product line was built from a single code base, and from it, every product ever shipped could be built.  The software manager was brilliant and forward thinking.  Every year around earth day, the software engineers had "earth week" and they went through the code removing the cruft.  When they were done, they tested the software, all the way back to the very first product shipped to insure that nothing was broken.
Auto-Generated Code

Reader Brian Cuthie pointed out an article that augers nirvana for the world of software engineering. Microsoft is making their AI available to auto-complete source code in an IDE for $10/month. Microsoft's tool will generate something like 40% of the software. (Alas, though the rest of this is a parody, the article is real).

Tech companies responded by firing 40% of their staff. Oil companies, always anxious to cut gas prices and reduce profits, are hiring displaced developers to build new refineries at a breakneck pace. Democrats and Republicans were united in praising these actions, noting that slashing ex-engineers' Silicon Valley pay to minimum wage will lead to an immediate dip in inflation.

Interviews with ordinary citizens were supportive. "Them software nerds just stare into a screen all day. Heck, they make nearly half what my dad did after years of slaving 12- to 13-hour weeks as a guard on Riker's Island, when he wasn't calling in sick. Typing ain't real work."

However, this is old news. As has been reported before if you're willing to spring for $11/month Amazoom's servers will auto-complete virtually all of the code required. Typically a developer needs to enter:

void whatever_man(

and the AI tool will then complete the rest of the function.

Amazoon spokesperson John Nevercode commented that they're deep into a project that will eliminate the need to even enter that one line of code. "Sensors will determine that a glassy-eyed over-caffeinated developer has just assumed a sitting position in front of the computer and then write the code," he said. "When it hits the build button, the AI will generate the executable, post sources to GitHub, and deploy the result worldwide. Testing is not needed due to the Deep Learning Algorithms©®™ already proven to create code that's good-enough for many applications."

When asked about the "it" in "When it hits..." the spokesperson muttered something about pronouns before murmuring sotto voce that the company anticipates replacing all humanoids with robots. He was immediately fired and the company issued a press release indicating that "in the interest of complete transparency and in an effort to keep our stakeholders fully informed, this is the last press release we will issue."

Initial deployments of machine-generated software have been very successful. The Bank of Fourth America's stock soared on their announcement that replacing all bank personnel with AI-generated software supplied by consultants Mckcrazy and Co., LTD, Esq, Inc., AG, YouAintGonnaSueUs, GmBH, decreased payroll costs by nearly 1% (the other 99% "impossible to trim" as it goes to the C suite).

(In unrelated news ScriptKiddies' four-line Bash shell sequence is making loans from The Bank of Fourth America available for a -100% interest rate. Collateral not required).

Ebenezer Tusk of Nikola Motors announced that their "Crashpilot" software is now certified for Level 5 driving. "Amazoom's software-generating tool cranked over 5 billion lines of code last week and the software seems to work," he Twelon-ed. "Ya know Joe - that guy in IT? His kid ran a car around our test track, and, other than that regrettable incident, things seemed to mostly work."

The DoD's troubled F-35 program recently got a $14 billion dollar software upgrade that was "immature, deficient and insufficiently tested." A Hexagon spokesman commented "hey, a billion here, a billion there, who cares? It's only taxpayer money and there's plenty more where that came from." Rumor is they will be replacing all 8 million lines of code with software generated by Amazoon's AI tool.

After all, what could possibly go wrong?
A Minimum Viable Product

Lars Weje Hangstrup disagreed with my take on minimum viable products:

I have never seen any Agile-evangelists suggest we should ship useless products. This is purely a decision of project/product management. Agile does not magically solve the challenges with collecting requirements or estimating milestone dates - that is the same difficult project management task as it always was.
"It will be done when it's done" can only be interpreted as the project manager having lost overview of the project, or a dysfunctional team. That sentence has nothing to do with 'Agile' or the existence of an MVP (minimum viable product)

If a project manager decides to ship the product prematurely, that is his/her decision. It has nothing to do with weather or not the team is working according to Agile principles or Waterfall or something else.
Sure, the main purpose of MVP is to get customer feedback, but it is also about purely internal stuff like, step-by step getting your

  • release procedure automated
  • acceptance test automated (and new tests added)
  • linter/analyzer settings right
  • code cleaned up
  • documentation in place
  • etc.

And very importantly: the current 'potentially shipable' MVP gives the project manager a clear information about exactly where on their timeline the project is. If he/she still is still clueless, that is a project management issue, and has nothing to do with the team being Agile.
Failure of the Week

From Michael Dunn:

From Neil Peers:

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.
Jobs!

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
Joke For The Week

These jokes are archived here.

Many readers pointed out that last week's joke is a circuit of a half adder.

From Evan Wasserman. Though not a joke, it might as well be:

Did you hear the story about a tech guy or got a vanity plate of NULL thinking his car might be invisible to tickets etc? Also people whose last name was NULL.

Car guy ended up getting tons of tickets with several thousand dollars in fines because tickets  issued to cars with no plates were entered as NULL.

Programmers did test for "NULL"  vs null for the plate field.   Result was that he was a match of for all these tickets.  Long hard fight to get it fixed.

Similiar problem with people whose last name as Null.  They could not apply or get things thru computers.

When the problem was explained, it was like a mini Y2K problem and they were told to change their name.     
About The Embedded Muse

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.