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.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• Shipping as a Feature
• MCU Forecasts (If You Believe Them)
• Writing in Software Development
• Failure of the Week
• Jobs!
• Joke for the Week
• About The Embedded Muse

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.

For every cycle a hardware engineer saves, a software engineer will add two instructions. Andy and Bill's Law

Daniel Quadros wrote: I highly recommend the book "Measuring and Managing Performance in Organizations" by Robert D. Austin. While the focus is on metrics for assessing personal performance, the discussions on Measurement Dysfunction should be remembered every time a metric is defined.

The giveaway is on holiday for the summer.

Enter via this link.

Too often we're so preoccupied with building the latest and greatest widget that we ignore customer needs. The most important person on a product team is the customer, even if that person or entity isn't involved in any of our decision making. After all, the customer is that magic creature who puts food on our tables. Sam Walton nailed it: "There is only one boss; the customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else."

Wouldn't it be cool to have downloadable firmware with mesh networking and 16,384-bit encryption on our new electric toothbrush? You betcha! Would that improve the customer experience? How many additional sales can we expect by investing months of engineering efforts and perhaps upscaling the 4 bit CPU to a liquid-cooled Hal 9000?

The customer sees features; that what gives a product its perceived value. Think in terms of features and benefits.

Suppose you're building a printer. It makes sense to list and prioritize the features that will go into the product:

But there's a critical feature missing from this table: shipping.

One of my beefs with some Agile practitioners is their seeming unconcern with ship dates. "It will be done when it's done" is perhaps sometimes a truism, but it neglects the harsh realities of the business world. You're not going to make money till the product is on the market. In the meantime, where is your salary coming from? Who is paying the rent?

People who work for small companies get this viscerally: unless there's another stream of revenue engineering is drawing down resources. It may seem the boss is irrational when pressing for a completion date but the bills come due every week. That's a fact that transcends the latest engineering approach or fad.

The hardest thing I've ever done was making payroll week after week, year after year. Is the product ready and shipping? Money is coming in! Is is still stuck in engineering? It's Friday, and, oh, crap, payroll is due!

(My business mentor ran a small, 100 person tech company. He told me that for 69 weeks in a row on the Thursday before payday Friday they did not have the cash to cover payroll. His creative - and maybe at times bordering on the brink of illegal - financial wizardry kept the business going. We in engineering felt the pressure to produce but had no concept of the strain he was under).

Shipping. Getting the product out the door. Generating sales and profits. How important is this feature?

Perhaps purveyors of large weapon systems (think the F-35 as a poster child) can get away with deferring delivery forever. But if you're a normal company that is just not an option. A week late and you might miss a press event. A month and collateral materials start getting stale. A year and another startup has cornered the market.

Or consider space missions: miss a Mars launch window by a week and you've added two years to the schedule. You just can't negotiate with planetary geometry.

The priority of shipping as a feature will vary with the product. But it is every bit as real and as important as any other capability we're building into the device. Miss the Christmas season with a new toy and you're market might be gone. A missed launch window is so unbearable that it might make sense to concentrate on a bullet-proof loader. Then you've got the 8 month coast phase to finish and upload the code.

Ultimately, getting the product out the door may be much more important than shoehorning that last feature into the code.

An interesting article by Jacob Beningo cites some new data showing the size and expected growth of the MCU market. One key takeaway:

It's funny data. The MCU market is, according to this forecast, more or less stagnant with little growth (in units sold) expected. That hardly mirrors the breathless excitement we've seen for the last decade of the IoT market, which some pundits claimed would top over a quad-zillion units per year. Is the embedded systems market tapped out?

My guess is no, but that's mere speculation. What I do know, however, is that these forecasts are generally wrong. I found this 2014 graph from the same prestidigitators forecasters in my files:

These sages predicted 49.3 billion MCU units would be sold in 2019; the previous chart gives 25B as the actual number. You could have purchased their analysis for thousands of dollars (the current report is $4950) and built your business strategy on their soothsaying.

Their numbers were off by almost exactly a factor of two. I wonder if an apology was issued?

Note the implied precision of the predictions: 49.3 B to be sold in 2019. Not "about 50B", or "45-55B". 49.3. What great wisdom these people must posses, such an uncanny ability to divine the slightest nuance half a decade into the future!

Over the course of decades one sees patterns, in peoples' behaviors, in politics, and in prognostication. I've followed analysts for a very long time, but have seen that few of their predictions bare much fruit. In the best of cases their numbers will paint a vague and hazy image of what will really transpire. Their oh-so-precise formulations are better seen as impressionistic paintings; a pointillism through which a bit of truth may be glimpsed if one squints hard enough. Or not: did anyone predict the recent supply chain shortages?

Much-maligned weather forecasters do a better job: They recognize that their imperfect data will be compromised by unpredictable uncertainties as the future unfolds, so produce hurricane charts with large cones of probabilities.

The good news for us is that the demand for our products continues to grow, and indeed the hectares of unsold cars awaiting MCU deliveries suggest continued demand exceeding supply.

So what will transpire? My crystal ball's cataracts permit no clear seeing; its fog swirls with clouds that mask the road ahead. But I remain an optimist for this industry, and fully expect our embedded creations will find ever more outlets. Another graph in Jacob's article shows lowly 8-bit MCUs still hugely successful, despite so many analysts having condemned them to the scrap heap for so long. Cheap processing has driven this industry since its earliest days; 8 bits are cheap; and I expect that force will continue to open new and unexpected markets for computing of all sorts.

It's time we recognize that software development is mostly about writing, not coding.

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. Donald E. Knuth

Al Stavely's book, Writing in Software Development, is a sorely-needed manifesto for the art of writing when creating software.

I read a lot of code and associated documentation, and, alas, find the state of the art to be essentially at a grade school level. It's ironic that engineers produce, more than anything, documents that are supposed to communicate ideas, yet we're so poor at written communication. Al's book is the Dutch boy's finger in the dike, a well-written attempt to show us what we must do.

Some of the book is patently obvious. Much is thought-provoking. The gestalt, though, really defines the essential work of a software developer.

The book takes some swipes at sacred cows like C since it "isn't even object-oriented!" I hardly think that condemns the language to the scrap heap.

One suggestion is to use a digital camera to capture diagrams drawn on a whiteboard. I first saw this working with a lawyer who captured all whiteboard presentations on his camera. Months later he'd still refer to those images. Grey cells are fragile containers of knowledge; digital representations preserve that information for as long as needed.

Another suggestion is to maintain documentation during development, making rough margin notes as you're working, and cleaning them up at the end of the project. I disagree. You won't have time, so those rough notes will be lost. Keep the docs clean all of the time, as we're supposed to do with the code. In other words, keep refactoring the docs.

What about Doxygen? Al likes it, but makes the important point that Doxygen adds no new information at all. It's a useful tool, but no substitute for careful documentation.

Al stresses using assertions as documentation. Parnas said "Just as in other kinds of engineering documentation, software documentation must be based on mathematics." Assertions can be a formal way of specifying the intended behavior of a function. Design by Contract, which takes assertions further by converting them into pre- and post-conditions, is one of the most powerful tools we can employ, both to generate correct code, and to document our intentions.

One interesting idea, drawn from Knuth's Literate Programming, is to write all of our code in a word processor, complete with all of the annotations needed. Using HTML tags and a relatively simple script, the build process strips the code from the file and feeds that to the compiler. A cool idea, but that generates problems when debugging as the "source" file is not the same as the file used by the IDE.  When, oh when, will the compiler vendors wean us from brain-dead text files, and allow us the formatting options we have given the word processing world for decades?

All in all, it's a great read and very worthwhile book. Amazon and other sell it, as does AbeBooks (my go-to source for used books).

Steve deRosier sent this animated GIF which I hope plays in your email client:

Andrew Newman wrote: The attached image came from a Sudoku app that I downloaded and started using on the iPad over the Christmas holidays. It seems that, when the board completion Time is longer than the Best Time, the "seconds" field of the Best Time is replaced by the time delta between the 'Time' (last completed board) and the 'Best Time'. It is displayed correctly only when the Time is also the new Best Time.

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

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.

These jokes are archived here.

I just read something on the internet, saying that Albert Einstein may not have actually existed!

Turns out, he was just a theoretical physicist.

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.