CC Blog Design Solutions Research & Design Hub

How Thin-Slicing Can Help Us

Written by Bob Japenga

The Search for “Fists” in Embedded Systems

This month, I discuss the origin of my use of the phrase “in thin slices,” and how it can help us design, debug, and test our embedded systems.


  • What is thin-slicing, and how can it help me in my projects?
  • What are “fists” in Morris code?
  • How can I rapidly detect bugs in embedded systems?
  • Embedded systems

A number of years ago, I was part of a leadership team wrestling with some long-term planning decisions. We were considering a major shift in one of our activities. I had proposed that we do some more study and reflection on the viability of the change. One of my teammates was incensed. “We have got to make a decision and get moving on this right now. Another study will bury the project.” I share this story to let you know that, in general, I err on overthinking a problem. I am a process-oriented guy who likes to work through all of the details before I launch on a new endeavor. I like our systems and our processes to be ever-improving.

I share this anecdote because this month I would like to build a case for (sometimes) making embedded system design decisions in the blink of an eye. In the process of doing that, I also want to celebrate the beginning of 13 years with Circuit Cellar as a columnist. As some of you know, I end every column with something like: “Next time we will wrap up this series and look at specific strategies that I have found helpful in debugging embedded systems. But, of course, only in thin slices.” Many of you weren’t with us when I started these columns and explained what I mean by “thin slices” (from which the column gets its name). So, let’s start there.

WHAT DOES THE TERM “THIN SLICES” MEAN?

First, some background. In Malcolm Gladwell’s bestseller Blink (Figure 1), he talks about the way we make decisions. In particular, he describes a process our brains go through called “thin-slicing.” Thin-slicing describes our ability to find out what is important with limited data. I have been designing embedded systems for 50 years, yet I find I am always a beginner. I always have limited data and a limited vision of what is coming next. The field is so broad, and the applications so varied, that no one person can completely understand even a small portion of the field.

FIGURE 1
Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell
FIGURE 1
Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell

Let’s look at some details from the book: In his first chapter, Gladwell focuses on explaining how thin-slicing, or rapid cognition, works in everyday life while making decisions. Gladwell states that, often, a little information about a person or situation is enough to make correct conclusions. He describes an experiment where friends and strangers were asked to evaluate a student’s personality (with respect to extraversion, agreeableness, emotional stability, conscientiousness, and openness to new experiences) based on observing their dorm room. The results of this experiment demonstrated that strangers were better overall at evaluating a student’s character traits than friends. Gladwell also notes that thin-slicing isn’t an exotic gift, but rather a “central part of what it means to be human.”

Later in the book, he describes John Gottman, a therapist who could predict whether a marriage would last at least 15 years based on spending just three minutes with them. If he could watch a 15-minute video, he could predict with 90% accuracy. And his success rate went to 95% if he saw a 60-minute video of them. In his book The Mathematics of Marriage, Gottman explains how he is able to do this. And Gladwell claims that it validates how thin-slicing, or rapid decision-making based on very little data, can be successful.

Gladwell tells another interesting story about intercepting German Morse code (Figure 2) during World War II. There were thousands of interceptors who listened to German broadcasts in Morse code from German military intelligence. The code was not in English or German. What is fascinating is that the interceptors couldn’t understand what the Germans were saying, but they could learn who was speaking.

FIGURE 2
Morse code
FIGURE 2
Morse code

The following is an excerpt from Blink. “The interceptors had such a good handle on the transmitting characteristics of the German radio operators that they could literally follow them around Europe—wherever they were. That was extraordinarily valuable in constructing an order of battle, which is a diagram of what the individual military units in the field are doing and what their location is. If a particular radio operator was with a particular unit and transmitting from Florence, and then three weeks later you recognized that same operator, only this time he was in Linz, then you could assume that that particular unit had moved from northern Italy to the eastern front. Or you would know that a particular operator was with a tank repair unit and he always came up on the air every day at twelve o’clock. But now, after a big battle, he’s coming up at four in the afternoon, and seven in the evening, so you can assume that unit has a lot of work going on. And in a moment of crisis, when someone very high up asks, ‘Can you really be absolutely certain that this particular Luftwaffe Fliegerkorps [German air force squadron] is outside of Tobruk and not in Italy?’ you can answer, ‘Yes, that was Oscar, we are absolutely sure.’”

In typical Gladwellian style, Blink has many other stories Gabout thin-slicing in a wide variety of fields. Thin-slicing is not foolproof. Gladwell admits that our thin-slicing can lead us astray and we can get it wrong. I once met a man for the first time, and within a few minutes he talked about me as if he really knew me. But his thin-slicing was completely wrong. A week later, I asked our daughter about him and she said: “He’s nice, but he comes off as if he knows you really well—but he is completely wrong in his assessments about me.” As I got to know him, I saw this over and over again. His thin-slicing was malfunctioning.

Gladwell also tells us that thin-slicing is something that can be learned. The marriage therapist was able to train others to accurately predict a marriage that was in trouble. And the Morse code listeners were able to teach others how to quickly identify unique characteristics.

DO WE NEED “THIN-SLICING” IN EMBEDDED SYSTEMS DESIGN?

After all these years of embedded system design, I feel like I know virtually zilch about the subject. I am constantly bombarded with things I don’t know. Datasheets for our processors were once nine pages long (the Intel 4004) and now run more than 3,000 pages. Our chips are so complex that testing one configuration every second would take longer than mankind has been around. The 4004 (Figure 3) had just over 2,000 transistors, while Cerebras’ deep learning computer system, the Wafer-Scale Engine 2, has 2.6 trillion MOSFETs (and 850,000 cores). We must learn thin-slicing to survive.

FIGURE 3
Intel 4004
FIGURE 3
Intel 4004

Which processor will be right for our project? On my first project there were nine to choose from. Nine total! Today there are tens of thousands of different processors. We have to learn how to make important decisions with limited information.

Which algorithm will work best in a particular application? I once gave an employee a task to design an algorithm for a critical embedded system. His algorithm was 20 pages long. Do we go ahead and implement it? Do I dig into his weeks’ worth of work to see if this is what was needed? I didn’t have time. In the blink of an eye, I knew that this was not correct and gave it to another designer who came up with a four-page algorithm. And that aircraft is still flying with that algorithm today.

How about in project management? Is this schedule realistic for this project? Are we even in the ballpark? As managers, we can’t always dig into all the details to evaluate a particular schedule. Yet we need to make a decision with lots on the line and little information.

I hope that someone will do for embedded system design what Gottman did for marriage: develop the markers—or, to borrow the term used for distinct Morse code rhythms, the “fists”—that would signal dead ends, projects that will never get done, designs that will fail, or algorithms that won’t perform. Is it possible? I think so. Marriages and relationships are much more complex than even our most complex embedded system. (One estimate, as discussed in Scientific American, is that the human brain has around 2.5 petabytes of storage. That’s 2.5 thousand times bigger than the memory in most of our embedded systems, assuming most embedded systems use less than 100GB of storage.)

As a first attempt, let’s try to determine if there are some markers that would help us to evaluate whether a bug is in hardware or software. I’m convinced there are some, and that we can get better at recognizing them. Over the years of debugging (I created a lot of bugs in my time), I found that I could “smell out” a hardware bug. How did I do it? I’m not quite sure. But my success at predicting them was high. As I mentioned, thin-slicing is not magic. It’s not even a gift—it can be taught.

CREATING FISTS THAT INDICATE IF A BUG IS IN HARDWARE

My February 2023 article in Circuit Cellar (“Debugging Embedded Real-Time Systems: Strategies to Determine if a Problem is in HW or SW,” Circuit Cellar 391) on debugging is a good place to start [1]. There, among the strategies, are seven fists (Table 1) that I have used to determine if a bug is in hardware or software. The other strategies in the article were procedural strategies for determining the nature of the bug.

Table 1
Possible fists
Table 1
Possible fists

None of these are foolproof. Sometimes, temperature can reveal a software bug, making it environmentally dependent. Remember, Gottman’s fists were not 100% predictive of a successful marriage. Memory fragmentation and memory leaks can make a bug only appear after long periods of operation. New hardware can run faster and expose software race conditions. But what if we can build a list of these (send me any suggestions and I will republish the list) so that we can debug faster through thin-slicing? I am convinced that with these fists (and others you provide), embedded systems developers could much more rapidly determine whether a bug is in hardware or software.

SUMMARY

Let me restate my hypothesis. We can create fists, or signatures, to aid in embedded systems design and debugging. Malcolm Gladwell demonstrates in Blink that we can solve complex problems quicker than expected (Figure 4). I’ve only scratched the surface. I would love to hear from you. Can you provide some other fists to help us get to the bottom of a problem more quickly? Perhaps you can augment the areas in embedded systems design for which I’ve proposed to create fists. More critically, can we get some serious research in developing fists to help speed up the various aspects of our work? I think it’s possible. Is there some PhD candidate looking for such a project? We certainly need it.

Next time, I want to explore requirements elicitation. How do we obtain the requirements for a project? But of course, only in thin slices. 

FIGURE 4
Blink - solve complex problems quicker
FIGURE 4
Blink – solve complex problems quicker

REFERENCES
[1] Japenga, Bob, “Debugging Embedded Real-Time Systems: Strategies to Determine if a Problem is in HW or SW.” Circuit Cellar 391, February 2023.

SOURCES
Cerebras Wafer Scale Engine 2 https://www.cerebras.net/
Gladwell, Malcolm Blink – The Power of Thinking without Thinking https://www.amazon.com/Blink-Power-Thinking-Without-ebook/dp/B000PAAH3K
Gottman, John; Check out the Gottman Institute for a host of resources https://www.gottman.com/
For The Mathematics of Marriage find it on Amazon: https://www.amazon.com/Mathematics-Marriage-Dynamic-Nonlinear-Bradford/dp/0262572303
Sharma, Chris; “How does the Human Brain Compare to a Computer?” https://www.crucial.com/blog/technology/how-does-the-human-brain-compare-to-a-computer published by Micron

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • OCTOBER 2023 #399 – Get a PDF of the issue

Keep up-to-date with our FREE Weekly Newsletter!

Don't miss out on upcoming issues of Circuit Cellar.


Note: We’ve made the Dec 2022 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Sponsor this Article
+ posts

Bob Japenga has been designing embedded systems since 1973. From 1988 - 2020, Bob led a small engineering firm specializing in creating a variety of real-time embedded systems. Bob has been awarded 11 patents in many areas of embedded systems and motion control. Now retired, he enjoys building electronic projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org

Supporting Companies

Upcoming Events


Copyright © KCK Media Corp.
All Rights Reserved

Copyright © 2024 KCK Media Corp.

How Thin-Slicing Can Help Us

by Bob Japenga time to read: 8 min