Constructing Software for Hardware

While developing a data logger for an advanced UAV inertial sensor I had to think about the quote below several times:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature.”
C. A. R. Hoare

Still my design is not simple, and still I have to discover the not so simple physical laws of that sensor :-(.

Inertial Sensor Setup

Inertial Sensor Setup

That quote from Sir Charles Antony Richard Hoare is so true. In case you did not know: he is the one who developed the quicksort algorithm. With this and all his other work he shaped the software and computer industry. And reminds me about the challenges and difficulties of constructing software……

Happy Constructing 🙂

3 thoughts on “Constructing Software for Hardware

  1. oh, how true it is, and how nicely phrased.

    since I also did some experiments with aviation instruments, another practical advice that I encountered was to modularise things to the level that each module is simple enough that can be written in one day. it sounds quite extreme, but with a proper design, and a properly tested library of components, it is achievable (well, maybe not one single day, let’s say in a couple of days). in my case the modular solution was a collection of CAN nodes, each doing a simple task (talking via a single interface to a single sensor/instrument/device).

    Like

    • In other areas the concept of ‘microservices’ is used which is a similar concept: one module or service just doing one thing. That makes it easier to implement, results in simpler interfaces and avoids overcomplicated and monolithic systems.

      Like

  2. Sounds close to the principles of “pure” functions and functional programming. Those go for functions that perform only one simple thing. Quite related to much acclaimed “inversion of control”.
    I do like the example where one could compare two programming approaches if he compares the styles of “printf()” vs “snprintf()”. Both do perform formatted printing, but only the snprintf() succeeds to isolate itself from doing unrelated things – like selection of destination interface and actually sending the data. what printf() has in addition.
    At the end this style brings independent, reusable functions and components (snprintf doesn’t know about fputc at all, with printf you have hidden dependency inside that at the end force you to create an fputc() implementation). Often this means that you have to take vendor’s HAL libraries and adapt them in a wrapper to implement your-company specific IO interface.

    Like

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.