Creeping elegance

Today I am going to tell you a tale. It is a true story of events that happened long, long ago in a land far, far away. We are always told that we should learn from our experience [or from our mistakes – it depends whether you do “glass half full” or “glass half empty”]. Hopefully, there are less painful lessons to be learned from the experience of others.

Once upon a time …

There was a young engineer, who was working on software for some fairly simple, 8-bit embedded systems. Although the term “embedded” had not yet been coined. The code was written in assembly language, but it needed to be modular, scalable and maintainable. Having worked on real time computer systems, he concluded that he needed a real time, multi-tasking kernel. Having no idea of any alternative option, he was very pleased to have the opportunity to design and write a kernel. The result of a couple of weeks work was a kernel that was pre-emptive and time-sliced with a background task. It worked well for the required application and the project was completed on time.

The next project came along and the hero of our story saw another opportunity to make use of his kernel. So, he spent a couple days enhancing it to incorporate some new ideas he had had from his experiences in the previous project. Then he used it as the basis for the new application. Once again, the project was completed successfully and on time.

The young engineer was feeling very pleased with himself and, when the third project came along, did not hesitate and used his kernel again. Just like the previous occasion, he invested a little time to improve the kernel based upon his experiences. And, yet again, he was very successful.

I can imagine that you are now thinking that this guy needed a “reality check”. Things were going just too well for him and he needed to be brought back down to Earth with a little bit of healthy failure. This is exactly what happened.
After the third project, it was decided to update the hardware that had been used in the first one and this necessitated modifications to the software. So, our hero dug out the listings of the code he had written a few months previously. He had a shock. What was this kernel that had been used? It was, of course, the one that he had written. But he had gone through two rounds of enhancements since then and his recent work only bore a passing resemblance to its ancestor.

He left the company shortly after this to pursue an opportunity with an embedded tools and RTOS company. As you may have guessed, that young engineer is now a rather older, grizzled engineer who often writes blogs on embedded software. I left behind me not one, but three in-house designed kernels. Fortunately I did a reasonable job with documentation, so I did not run away from a terrible mess. However, if I had been able to source a commercial real-time kernel, I would have only left behind a single, comprehensively documented software package.

In recent years, I have frequently given a talk looking in detail at the issues that should – in an ideal world – drive the decision to make or buy an RTOS, as this is still a subject of debate. Do let me know if your company needs advice on this topic. I have also written a freely available paper, which you may wish to download.

I think that I learned from my experience …