Why does my firmware need … honesty?

There are some things that have been believed for so long, and so universally, we don’t think to question them. Mostly, this makes sense: we believe them because they’re right. But it isn’t true in every case.

The waterfall method of design is an infamous example. It took a carefully-applied dose of doublethink to do what actually worked, while still believing that waterfall was correct. We weren’t deliberately lying to ourselves or each other; we didn’t (consciously) realise what we were doing. And this is the sort of (dis)honesty I’m referring to. Intentional deception is very rare in firmware design, in my experience.

I think I may have spotted something of this kind. Let’s see if you agree. 🙂 Many commentators publish articles and books containing good and wise advice. [No irony intended: their advice is good and wise, as far as I can tell.] But they often seem to assume that we (designers) are all good (enough) at what we do, and that we want to get better at it. There are many working developers who do not meet these criteria. This matters because the advice often depends for its goodness and wisdom on its recipients (us) being both able and willing to take its recommendations on board.

Ego-less code reviews, for example, are often recommended, and with good reason. But some of us can only manage this some of the time, and some of us can’t do it at all. We’re human! We exhibit human failings. So ego-assassination code reviews are more common than we would prefer, with all the negative consequences we might expect. [Better not to review at all than this?]

I’m not attacking humans. What would be the point? 😉 But I do think the design practices we create and recommend should be suitable for real designers, not just for Vulcans or androids. I think there’s a point in that, and I think it may be one of those things we’ve accidentally ignored for too long. What do you think? Do I have a point? Are there other things we ignore, that we should look at more carefully and more critically? How about leaving a comment? 😉

“Who cares, wins.”

This blog post is the latest in a series that is longer than I expected it to be. Their main (intended) purpose is to stimulate discussion, so please leave a comment. Thanks for dropping by! [Find me on Twitter as @Patternchaser.]

Why does my firmware need … state?

State — that’s static variables in firmware-speak — is considered harmful by hipster designers. But they are as different from us as two software specialisations can be. They live on the Ethereal Plane. [Why do you think it’s called “Ethernet”? 🙂] They belong to different schools of magick from us, they cast different spells, with different intent, in their world of nets and webs. State introduces problems for them.

The arguments hipsters have put together to vilify state have merit, but many of their objections describe problems with state in the context of their Ethereal Plane. They do not affect us or our firmware. What remains after we discard these context-specific objections is that state represents a hidden parameter passed to every method when it’s called. No programming technique is without its downside, and that is a downside of state.

State is unavoidable in firmware. Our applications contain tasks that are continually executed. In between task invocations, the state of each task is stored. When that task is executed again, its state tells it where it has got to, and (therefore) what to do next. Unless we make radical changes to the way we design — and this is not impossible… — we need state.

Another objection to state is that it makes code more difficult to test. It does, but so does any addition to existing code. Instead of just testing a method once, we have to run each test in every possible state. This is not a reason for us to give up on state, but it is a reason to minimise it. An application with too much state becomes difficult to understand and, eventually, impossible to extend or maintain. Clearly, some caution is appropriate in our use of state. But caution is appropriate to all of our coding, whatever we’re doing. It doesn’t just apply to state.

Hipsters found problems, and traced them to state. At this point I think they adopted the belief that state is bad. Then they searched for justifications for their beliefs, and they found some. That some or all of their arguments are valid doesn’t change what they have done, and are doing. They seek to optimise their working practices for their world, and the work they do, which is eminently sensible. And for them, the bad points of state outweigh the good ones. For us, that is not necessarily the case, and we should resist being carried along with the tide, just because that’s what hipsters are doing.

State is not harmful, but it should be used with care.

“Who cares, wins.”

This blog post is the latest in a series that is longer than I expected it to be. 🙂 Their main (intended) purpose is to stimulate discussion, so please leave a comment. Thanks for dropping by! [Find me on Twitter as @Patternchaser.]