Why does my firmware need … design?

It doesn’t! There is no part of the process of creating an executable to meet your customer’s needs that requires design. It’s you that needs it, because you’re human. Humans are not good at dealing with complexity. Without mnemonic tricks, we can only hold three or four things in our minds at one time, and so on. Over the millennia, we have developed techniques to help us deal with complexity. Collectively, we call them ‘design’.

It is perfectly possible to create firmware executables without applying design; we can just sit down and ‘do it’. XP first emerged as a reaction to the design-heavy processes and methodologies prevalent at the time. In the way of humans, some practitioners pounced on XP as a reason for doing no design at all. This is a misunderstanding. We need to return to the middle path, whereby just enough design, and no more, is the preferred approach.

Design is the name we give to the toolset we use to produce our firmware. A wood-cutter could fell a tree using only teeth and fingernails, but an axe offers considerable advantages! Design helps us to produce a structured response to our customers’ needs, and that structure helps us humans to manage and understand our own designs.

Abstraction is an important member of our design toolset. It involves stripping away detail so that we can more easily see the underlying structure. By creating a layered, abstracted, design, we can divide and conquer, somewhat akin to the application of reductionism in science. We divide each larger problem into a collection of smaller, simpler problems that are easier for us to deal with. We do this enough times that the small problems we end up with can be understood and solved easily.

So this is why our firmware needs design. And, just as our programs should be as simple as they can be, but no simpler, they need just enough design, but no more.

This is the first in a short series of short blog posts. Their main (intended) purpose is to stimulate discussion, so please leave a comment. Let us know what you have to add to the discussion!

Why does my firmware need … design?

One thought on “Why does my firmware need … design?

  1. Great thoughts on this. I’ve worked with some that spend weeks on end creating design documents (had to do some for them as well) and I’ve also flown by the cuff and ended up in a mess of code. I’ve also found a good balance between the two and create enough design documentation to structure out the main pieces and then get to coding.
    “A wood-cutter could fell a tree using only teeth and fingernails, but an axe offers considerable advantages!” <– great analogy!

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s