Mastering Embedded Systems Archiv

I have recorded this episode twice. Not by intention - far away from that. But I was neither convinced nor satisfied with the first recording. Also the subject was not really impressive and I decided to do it again from scratch. Thus I got a first hand impression what waste of time and effort is. However one detail in the first record was amazing. It was about waste in SW-development. You remember episode 4? Already there I have mentioned waste due to over-processing and over-engineering. Both are part of the 7 forms of regular waste in any kind of system. The Toyota Production System (TPS) has introduced to a broader audience the classification of waste forms. In this episode I wanted to connect traditional manufacturing based Kaizen and Muda, Mura, and Muri with Software-development. Is it possible? Do we have parallels? Or is the TPS not adaptable to nowadays IT-based technology? Stay with me and enjoy the show.

I have mentioned the Embedded Testing conference in Munich in episode 20. One of the presentation was about "Applying DevOps Principles to Software-Hardware Integration Test". Vassilis Rizopoulus, naming himself as DevOp and Tester, explained further details, their tooling, automated testing and the mandatory environment. I was excited and we have had an extraordinary talk after his contribution. Some days later I asked him for an interview. I am sure that Vassilis' ideas and thoughts will be helpful for a lot of engineers out there. Especially engineers who wanted to try something knew, but who might need some trigger to change their way of thinking and habit. Vassilis works as an engineer at Zühlke in Germany since 2001. He has tons of experience and knowledge. According his own statement on his company blog he has "... helped build software for devices as small as a cookie to as large as a 60-ton locomotive". Moreover he was co-organiser of the European Ruby Conference in Athens in 2013. You see, Vassilis is an outstanding personality and I am very happy to present you this talk. We're discussing about DevOp-priniciples. His will to automatize everything. The infrastructure you need for day-by-day development. And of course the mother of all questions: what are the differences between SW-tester and SW-developer.

In episode 20 I have described the main differences between traditional conferences and the idea of BarCamps. In this session I wanted to give you my 15 for your BarCamp visit. I have meanwhile joined several BarCamps. And I have made a lot of things wrong. Mainly because I was not aware of. Sometimes also I thought it is better done in another way. But there are a some main phases you are confronted with. And for all of them you can do things well and you do things much more better. Starting into a BarCamp well prepared lets you enjoy the atmosphere even more intensively. You get much more quicker into connection with the other BarCamp-members. And you finally get more out of the time you're staying at the event. All BarCamps can be separated in three different phases: BEFORE, DURING and AFTER the BarCamp. Even the AFTER phase is as much important as the other phases. If you do not care for the AFTER-phase you loose a lot of momentum you have gained during your time before. Please take these 15 tips into account. Let your first or next BarCamp-visit become an even more thrilling success.

Holy moly, seems I'm getting old. Two times in the last two weeks I was confronted with the PDP-11. Things which are part of my experience are nostalgic for others. They have never seen or touched them. Never experienced in real life. What has happened? One day I saw an update in LinkedIn highlighting DEC's PDP-11 as an old system. That's nothing extraordinary. It is old. But one of my colleagues mentioned it as nostalgic. Bumm, right in the face. Second, I got a mail by another colleague. In his signature he mentioned that this mail was written from his PDP-11. I doubted this, but he showed me a picture showing him from the backside (hopefully it is him) and a PDP-11 aside. That picture must be old. I do not consider that he really has a PDP-11 in his cellar. But both moments let me think back into that time 30, 40 years ago. Computer Systems were different. Computer Science was slightly different. And of course the systems you own or you could directly touch were dramitically different. Compared with the systems available nowadays the are more like flintstones than real lighters. And these thoughts created this episode. I wanted to go back with you showing some highlights in my computer-life. Not for nostalgic reasons, but to make you aware that things were really different at that time. And that it is of some benefit to know a little bit about it, to understand the situation we're currently in.

You know conferences. For sure you do. You might be a fan of them. Or even not. You might be even disappointed, as I am after visiting the Embedded Testing 2015 in Munich last week. Although I was invented as presenter, I was not convinced. I mean the topic was really good - no other conference or meeting available covering exactly this specific part in the Embedded Systems realm. But the conference got stuck as a sponsor-driven event which highlights products over general knowledge, marketing over sharing of experience. One could have made a lot more out of this conference. So the participants have finally had only their others to get acquainted with each other, hear the problems, discuss and finally detect the old rule, that the best of conferences are the pauses. Free time which can be used for connecting and sharing. In this episode I wanted to highlight the approach of traditional conferences in comparison to BarCamps. A BarCamp is an un-conference born from the desire for people to share and learn in an open environment. It is the direct response on all attendees who wanted to create and design their own agenda of content. For me BarCamps, the un-conferences are by far the better conferences. Listen to this episode and create understanding about this popular approach to confer.

Talking about bug-hunting has become a regular topic in this podcast. However there are tons of different persons out there using their own approach to handle bugs. All of them might have different attitudes, different approaches and different experiences. And it might be of interest to get more familiar with them and the details they can tell us. Within today's episode we have Bero Brekalo as a guest for interview. Bero is one of my very first listeners not directly related to me. We got acquainted after release of Episode 2. We have had a long mail-discussion about debugging, our different and common understanding. Especially Bero's very interesting debugging tools made me curious. As more as we discussed and as more as I got familiar with Bero, I more and more get the impression, that he's Mr. Bug-Hunting in person. Today I have the pleasure to present you Bero Brekalo. We're talking about many details of debugging. You get further details about his approach and his understanding of debugging. And you get acquainted with a very experienced engineer, who has gone through a lot of storms and bad weather. Let's stay with me and enjoy the interview.

Everybody has his limit in handling emails. For one 10 per day are too much, another handles 150 without any problems. But sooner or later, everybody of us have to declare: it's too much. I have had a time in my life in which I have had to handle 750 mails per day in average. Nobody can say that this is possible to do. But that was the time I started a very strict and consequent filtering and categorization. However it still was too much. The combination of importance and urgency was back-breaking. In the first part of this episode I will show you some of the most successful approaches how to handle the flood of emails daily arriving in your inbox. There are different concepts, sometimes even contradicting systems, but give them a try and find the most acceptable way for you. But if you're in the same situation as I was, even the most sophisticated approaches to handle the flood, weren't succeeding, then you might be interested in the 2nd part of this episode. This summer I stumbled over the book of Rory Vaden "Procrastinate on Purpose: 5 Permissions to Multiply Your Time"". Rory was welcome as guest in the Art of Charm Podcast His book was an eye-opener. I do not agree with everything Rory has written, however the major part, the introduction of a 3rd dimension, was essential. If importance and urgency are the first two dimensions, significance becomes the 3rd dimension.

Do you have ever heard about Soft-Errors? No, I do not mean Software-Errors. That's something completely different. I mean Soft in difference to Hard. I first time get into contact with Soft-Errors in late 2011 as we have observed a spontaneous reset within a customer's appliance. There was no indication for a reset-request, the system simply resetted. Within some industries this is no case to be worried about. But in that time, in that type of industry, with this particular customer it was a challenge to find the root-cause of this spontaneous reset. And it was even more complicated to approve this root-cause. In this episode it is Michal Lewczyk joining us. Michal is one of the very seldom specialists available for Soft-Errors. Michal was one of my colleagues in 2011 and the years after. He was the main investigator for all Soft-Error issues we suspected. Michal has a deep knowledge in bare metal SW-programming. He's mainly engaged into developing software for Digital Signal Processors; thus he's not only an elaborated and experienced software-engineer, but also a great investigator and marvelous bug-hunter. Let's enjoy the engineer's talk with Michal Lewczyk about one of the most quirky phenomenon in Embedded Systems.

In this episode I will give you further details and helpful hints how you can do all the aftermath in running and working with task-forces. You get a lot of details about how to provide meaningful and reliable meeting minutes. I provide you my experiences in doing minutes both, during and after the task-force meetings. Additionally you will also get my minutes template available for free at Google Docs. And last not least I will drop you my ideas about the retrospective you should have for each of your task-forces.

In this episode I will give you my thoughts and considerations about the Volkswagen Diesel scandal. I wanted to highlight some of the obvious technical problems as some of the not that visible intrinsic issues. Where do we have seen this kind of cheating before? What could the customer expect? How will Volkswagen deal with the situation? A big amount of questions let me consider about some potential answers or thoughts how this could have happened, why it has happened and whether it is not that simple to resolve the problems.

This episode is the 2nd part of the root-cause mini-series. It has started with episode #9 and the 5-Whys technique. This time we get introduced into the Ishikawa-technique. It is a much more versatile approach which handles even more complicated problems with more than one root-cause. In detail the Ishikawa-technique is a simple as the 5-Whys. However it also has some problems and obstacles which you should know to use it on its best. This episode provides you an introduction in this graphical cause evaluation method.

In this episode you will learn a lot about building, maintaining and distributing tools and operating systems in large scale projects. With Robert Schiele a senior expert on all this kind of topics stays with me. We're talking about build-systems, root file systems, native and cross building. We tackle observable problems with distributed environments. We discuss about struggles with multiple hardware platforms. And we give you a close look into the way how well prepared tools-provisioning saves you time and prevents waste.

Complicated technical problems, defects, situations or environments often need some abstraction to be understood by outsiders. This episode give you 6 ways to fail with your explanation. But it also gives you six great ways how to become a 1st class insider providing exceptional explanations.

This is the vacation episode. Recorded on my way to the beach of Moliets-et-Maa. Moliets-et-Maa is a small village in south-west of France. It's situated close to the Atlantic sea. Roundabout 120 km south of Bordeaux and 50 kilometres north of Biarritz. It's a surfer's spot and offers a 9- and 18-hole golf course. We love it due to the great sea view, the wide beach and the lovely weather conditions. It's also my 10th episode and therefore time for a short celebration. Hoorray. Okay, that's enough.