Now is the time to say goodbye…

Hi Sam,

I retired just as you started out as a firmware designer. I want to pass on something, both to round off my career, and to offer yours a flying start. So I’ve based this on my time-travel letter. You know, the one that old-me sends to young-me, brimming with wisdom, wit and good advice? 🙂 So here is a view of my career, in the context of my learning to do what a designer does. [That is, to get from customer needs to an executable that meets those needs.] First I’ll cover what I learned while writing this (more than I could possibly have imagined!), and then the things I learned that I can date, if only roughly. Then I’ll describe the things that just crept up on me.

When I started this letter, it was to be the list of ego-driven imperatives that you might expect from a programmer. 😉 But young-me would’ve binned a list of commandments without compunction, and I’m sure you would too. So the first thing I learned is that I need to offer you something useful, or you won’t read it. This is my best effort at that. Enjoy! 😉

As I looked back with the wisdom of hindsight, I made connections I hadn’t made before. Things I had thought important or significant turned out to be neither when viewed from a historical perspective. And things I had overlooked turned out to be pivotal. If I’d known how much I would learn from serious consideration of my progress, I would’ve done it every ten years. No less than that: we need the temporal distance for hindsight to work. Ten hours of solid introspection, every ten years, would’ve vastly improved my rate of progress!

The jobs I had, in the order I had them, influenced my journey more than anything else (except a mentor) could have done. My employers’ attitudes to training, the provision of tools and equipment, their development processes, and the work that was available for me to do, defined and constrained how I could progress. If I could do it all again, I would give much greater priority to selecting the right employer for me, at that point in my career.

My first job offered three highlights: I learned C, got exposed to an OS, and had to leave in a hurry.

Having previously flirted with FORTRAN, BASIC, assembly language and Pascal, I picked up C quite easily, and learned that all languages are basically the same, and provide the same features. I had a shock when I encountered C++, but it was true for the languages I had encountered so far.

We used OS-9, a multi-user, multi-tasking OS. Uniquely in firmware, we used it on our development and target systems. Having learned the benefits of an OS on the target, I was open to RTOSs when I encountered them later.

I also learned an uncomfortable lesson in reality. Friday morning: we told the boss we would have something working in 6 to 8 weeks; Lunch: the boss promised the customer a demonstration on Monday; Late afternoon: the boss instructed me to work 20-hour days over the weekend to reify his lunacy. I refused, and had to find a new job. Not all lessons are happy ones.

My next job was a disaster, something else I only realised while writing this. As I look back, I can see nothing worthy of mention, and I was designing firmware there for five years! I should’ve been aware of my stagnation, and moved on sooner. As it was, I moved when our senior managers destroyed the company. I suppose that was a lesson of sorts.

My next job introduced design methodologies, Quality Processes, OO and C++, software patterns, and I gained access to the internet. I learned a lot in my ten years there. [Sadly, as above, I also left after senior managers destroyed the company.]

I mistook design methodologies for ‘design’, at first. We used Schlaer-Mellor, which wasn’t known as S&M for nothing. Of course, there was no training; we were expected to pick up what we needed by our own undirected efforts. I learned doublethink. We pretended to use waterfall. We dutifully wrote and reviewed useless documents. But we actually did what we needed to do to make our firmware work.

I encountered Quality Processes for the first time, and learned that a QA process can be a good thing, if (and only if) it helps us make quality products. I learned to be an ISO9000 auditor, to add credibility to my claim that you can have a firmware development process that is useful, usable and ISO9000-compliant. [In a later job, I wrote such a process, and we used it with success for years.]

This is when I got internet access at work. No websites yet, but I could access mailing lists and newsgroups. My learning had been limited to books and magazines. Now I discovered software patterns and OO, and gurus like Cope and Uncle Bob. I learned so much from these people! I asked ignorant, arrogant questions, and they responded with patience and courtesy. <blush> I started to get a proper idea of what design was/is, and even how I might go about practicing it. I conversed with some of the greatest software designers of the last 50 years. Not on equal terms, you understand. But I did learn.

It is unfortunate that my employer was unwilling to let me deviate from company processes and practices, to try out some of this amazing new knowledge. [My next employer was the same, but I played dumb, and started using TDD and software patterns anyway. When they queried me, I acted surprised that they didn’t already use them, and got away with it.]

In my final job, I applied what I had learned. I introduced them to software patterns and TDD (as I mentioned above), and wrote a firmware development process that (I think) is still useful and in use. I started to take part in product design discussions much earlier. In short, I was doing design properly. When I finished, I still had ideas that I hadn’t got around to trying, but I was doing good work, and still getting better at it. Then our employer closed and outsourced our development department. As suddenly as that. And that was it.

We have covered all my employers now, but there are other things I learned that I can’t tie to a time or a place. These are they:

There are no binding rules or laws in firmware design, only guidelines. But our guidelines are based on years of thought and experience. They may be broken freely, but only if you can justify it to your peers in a design review! There are no laws, but you are not thus a law unto yourself.

Perspective is a magical spell, stolen ages ago from the Plane of Design. The more you have, the better. Mostly. Sometimes, irreconcilable requirements can be reconciled just by finding and adopting the right perspective. Perspective also evokes viewpoint, paradigm, metaphor, analogy, vocabulary (words, symbols and concepts), and so on. It’s about the way you (choose to) look at something. Imagination is the only limit. See yourself standing on the API of your new class, looking out at the application. Look at your design from a Taoist perspective, if it helps.

Simplicity is not a virtue, it’s a necessity. But avoid the mistaken KISS acronym: it isn’t stupid to produce complex designs, it’s human. The quote usually attributed to Einstein — “as simple as it can be, but no simpler” — is a much better guide. As well as the obvious message, it also warns us that a too-simple solution cannot adequately meet all of its requirements. Simplicity is hard work, but we need to pursue it, or complexity renders our designs unmanageable and incapable of change.

Clarity is second only to simplicity when it comes to desirable attributes our designs should display. Everything about a design should be clear: code, diagrams, documents, processes…. Everything. [Code] readability is just clarity by another name, and we all know how important and valuable readability is … don’t we? 😉

The ‘just enough’ concept is strongly related to simplicity. It applies to everything that has an optimum value that lies between extremes. Just enough documentation, design, testing, and so forth, are things to aim for. But there’s no such thing as just enough bugs….

Context is all, as it is for many disciplines. Designs don’t exist in a vacuum. Neither do designers or design teams. Context is almost always more extensive than we think. Your manager, that guy who compromises your work with those ridiculous demands, is part of your development context. You are too. Consider all influences on your firmware, whatever they are. If you cannot control them, at least be aware of them, and their effect(s).

Discussion is useful when co-operative, and counter-productive when adversarial. We developers have to find a way to embrace this, and many of us find it difficult. I did. I made the final push when I realised that, if I didn’t grow up (in this particular way), I could progress no further as a designer. [Being a designer meant, and still means, a great deal to me.] Find your own reason to avoid the worst consequences of ego, without losing your opinions, creativity or imagination.

Best wishes on your journey,

Great-uncle Pattern-chaser

Sam is my fictitious relative, invented for the purposes of this article. No firmware designers were harmed during the creation of this document.

This is my final firmware blog. As time passes, firmware development recedes from me, and what I have to offer becomes less useful, less helpful, and just … less. Thank you for reading. If you care to leave a comment, that would be great.

P.S. I reserve the right to edit and add to this blog as improvements occur to me. If I could’ve made it perfect first time, I would have done! 😉 Continuous improvement, as they say…. 🙂

Edit #1. 05/12/2017. Minor text clarifications. Added a paragraph on ego.

Edit #2. 06/12/2017. Added paragraph about clarity.




Now is the time to say goodbye…

Law and order

From the Collins English dictionary:

·        Law. n. a binding force or statement

·        Rules are instructions that tell you what you are allowed to do and what you are not allowed to do.

I grew up with an understanding that rules and laws were authoritative and binding. Perhaps this is because I was raised by Roman Catholics, in a strongly commandment-oriented culture. But perhaps not, as the above definitions illustrate. [There are other definitions for these words too.]

When we look at laws and rules, we find that few of the associated meanings confer binding authority. Even the ones that do are artificial, like the laws of our land, whose authority is actually our authority. The law of gravity is a description of how the universe operates, and it is bound by the universe, not vice versa. The laws of mathematics are definitions, created by us, and given by us the status of binding and authoritative law (strictly within the context and world of mathematics). The laws of software design (my profession) are guidelines, albeit tried and tested ones. And so on.

N.B. Out of respect for believers and non-believers alike, I will leave discussion of divine law for another day. 😉

Then I looked more closely at the laws of my land, the UK. After watching the TV drama Law & Order: UK, I started to think that most of the problems they highlight could be avoided with a bit of common sense? Then I remembered another TV drama, Judge John Deed, “a High Court judge who tries to seek real justice in the cases before him.”, as Wikipedia says. This is the problem, I think. Our courts rule according to the letter of the law, not its intent.

I have always thought that ruling by the letter of the law was stupid and petty, but that’s not much of an argument to throw against it. But why on earth would we set aside the intent of the law(s) that we have made? Surely that’s the important part?

A real-world example: the EU discovered that unscrupulous manufacturers were injecting water into ham, to maximise their profits. They introduced a rule that ham may contain no more than 5% added water. Instead of righting the wrong, reputable manufacturers all added 5% water to their ham. After all, the rule confirmed this is acceptable (i.e. not illegal) behaviour. Thanks to human nature, the rule had the opposite effect to that intended. A court that ruled according to the intent of this rule would’ve resulted in a different outcome, I think.

Ruling according to the letter of the law denies and prevents justice. Legal technicalities are one example, but there are many more. If we rule according to the letter of our laws, we must write those laws to cope with all circumstances in which they might be invoked and applied, without knowing what those circumstances will be! This is quite impossible.

Consider the easy, black-and-white, case of our law against killing other human beings. What about soldiers? OK, we’ll write an exception. Self-defence? Another (possible) exception. Defence of others? Euthanasia? Abortion? Even an ‘easy’ case is not so easy when you think about all the different ways in which it could or should be applied. When a law is broken, it happens in a context, a set of circumstances that are genuinely unique. Can we formulate laws that cope with this? Our history says no.

By empowering our courts to use our laws as guidelines, as they should be, we enable them to provide justice. We enable them to follow the (hopefully wise) intent of our laws, and of the skilled law-makers who make them. If there is a context in which a particular law-breaking is acceptable, even admirable (and there will be such, even if they don’t happen often), our courts should be free even to reward the citizen(s) concerned, if it’s just.

There are no laws or rules that we could usefully consider to be authoritative and binding. I’m glad I’ve got that off my chest. ;)

Law and order

Hi-fi and Windows 10

The Chord Mojo is what you buy if the sound from your mobile or laptop isn’t all you could hope for. It plugs into your device and bypasses your inboard sound hardware with something much better. You probably connect your TV sound through your hi-fi; this is the same thing, for the same reasons. I wanted to write a review of the Mojo, but I don’t have the experience of competing products, and so on. [If you want a proper review, here’s a link.] Anyway, the story went its own way, as you will see. For now, here are my, er, opinions of the Mojo.

Mojo does two things better than most: transients and notes.

Good transients let you hear the start of each note, and the rest of it then follows on quite easily. This helps distinguish the instruments, and makes the music clearer and easier to enjoy. This is especially helpful with low-quality recordings. Your low-bit-rate mp3s will still sound murky, but better. Higher quality files will sparkle accordingly. 🙂

I thought I left one-note bass behind years ago, but I hadn’t. At least, not to the extent that Mojo plays notes. The effect covers the whole spectrum, but is more obvious in the lower registers. Bass and drums, in particular, have a note as well as a sound.

Good transients and good notes lead to good timing/rhythm and good tunes. What more could you want? 🙂 Mojo delivers a full, balanced and well-rounded sound. Follow the Golden Rule, and listen for yourself. As for me, I’m rediscovering my music collection. I am living the cliche! 🙂

Configuring a Windows PC for hi-fi sound

I had some difficulty configuring my laptop to reproduce hi-fi. The problem lies with Microsoft Windows. It is nothing to do with Chord or the Mojo. You can’t avoid this irritation by buying (say) an Audioquest Dragonfly instead. The same problems apply. Having said that, Chord market the Mojo for use with Windows PCs….

Normally, when you plug in a new USB device to your PC, it auto-loads a driver, or you download one from the vendor’s website and install it, and you’re done. This is not the case with a music device.

Windows 10 will grab your music, and process it as it knows you would want, if only you were as clever as it is. 😦 It will run your music through its mixer and volume control, up- or down-sample your music, and who knows what else. This is Windows’ default sound scheme, called Direct Sound. To avoid it, you will need to put in some extra and unfamiliar effort. You need to use an alternative sound scheme: ASIO or WASAPI.

“Bitperfect” is a misleading term to describe a system whereby your music player program can pass the music direct to your Mojo without Windows getting its grubby hands on it. Only ASIO and WASAPI support this. I can hear no difference between them, and the hi-fi community seems to favour ASIO, so that’s what I’ve gone for.

To use your audio device, you need to install ASIO at both ends. Download and install Asio4All. This will connect the ASIO output to the Chord driver, and thereby to the Mojo hardware. Then you must configure the front end, your music player, by enabling it to support ASIO. Chord support JRiver, but I found it painful to use, and went for foobar2000, which is almost as well regarded, and it’s free. But you will still need to download and install a ‘component’ to support ASIO operation.

If this is too much for you, try WASAPI instead. A single component for foobar2000 will get you going.

One other thing. Some Windows PCs can become misconfigured. This results in intermittent and severe problems with channel balance. It isn’t just that one channel is missing, it’s more complicated than that, but your ears will know if you have a problem. If you do, as I did, you need to open a console box (right-click on cmd.exe and select ‘Run as Administrator’ — this bit is important) and type:

net localgroup Administrators /add networkservice

net localgroup Administrators /add localservice

This should solve your problem.

Finally, you need to enable ‘exclusive access’ to your audio device in the Windows driver settings*, and you should be able to listen to hi-fi on your Windows PC. At last. 🙂

* — Go to Settings/Control Panel/Sound. Select your output device, then Properties, then the Advanced tab. Tick both of the ‘Exclusive mode’ boxes.


I spent 32 years developing software (not Windows software), using PCs as a ‘power user’ since 1983. And I’m not especially stupid. I promise. But I misunderstood, and bought a £400 product after auditioning on an incorrectly configured laptop*. [It’s lucky I’m so delighted with it!] Learn from my mistake.

* — N.B. This is not the fault of my dealer, Audio T. I told them my laptop was correctly configured, as I thought it was. Mike (Audio T) and Tom (from Chord) helped me sort all this out, once I told them I had a problem. Thanks to both of them!

If you’re anxious about all this, you could ask your dealer to help configure your Windows computer. I’m sure many of them would be happy to assist a valued customer like you. 😉 Alternatively, if you have the option, you could build your music machine using Linux. 😉

The Chord Mojo is a little box of joy and wonder. You should treat yourself to one. You won’t regret it.

I have a degree in Electronics, and I worked in electronic hardware and software design for many years. I have no qualifications as a hi-fi reviewer, and no connection with Audio T or Chord, apart from being a satisfied customer. I am a lifetime hi-fi and music enthusiast. I am not a huge fan of Microsoft Windows.

Have you had problems with hi-fi on your Windows 10 PC? Please leave a comment. Thanks for reading this. Oh, and if you expected a firmware blog, I’ll try to do better next time. 😉


Hi-fi and Windows 10

How we hold knowledge

We tend to hold knowledge in one of two ways, consciously and intuitively. Consciously-held knowledge is what we have learned by study and practice. Oddly, it is (sometimes) not easily usable by designers, as we cannot ‘feel’ what’s right.  For that, we need the knowledge to be held intuitively (unconsciously). Oddly, it is (sometimes) not easily usable by a designer, as we cannot articulate or describe what we know in our gut.

To be really great designers, we need to internalise our consciously-held knowledge until we can ‘feel’ it too. This isn’t so bad, it just takes practice. [Lots of it.] But we also need to bring our vague gut knowledge out into the light of conscious consideration, and this is hard. The joy when you consciously learn something you already knew is better than sex. [YMMV] It is the stuff of ‘aha’ moments. But how to consciously seek it out, to aim for it? I don’t know, do you?

The conclusion I draw from this brief consideration is that only knowledge held consciously and intuitively is knowledge that can be fully utilised. I didn’t expect that. Did you? 😉

How we hold knowledge

My most life-changing decision

A little time ago, I tweeted this: “>50y ago, I was fixated on symmetry; decided to seek out beauty of asymmetry. Turned out to be most life-changing decision I ever made.” A couple of people suggested I expand this, and blog about it, which surprised me, but here goes:

I have no idea when I made this decision, but it must have been when I was quite young. I could’ve been 3 for all I know, but it seems unlikely. And, given the known shortcomings of human memory, the memory I have may not be what happened. I.e. what actually went on in my mind.

Anyway, I became aware that I was too fixed on symmetry. I loved squares, but only liked rectangles. I shied away from asymmetry, as an almost emotional thing. I recognised this too-fixed mindset as something undesirable, and decided to school myself to appreciate non-symmetrical things too.

This was a literal and metaphorical thing. I opened my mind to quadrilaterals without even one right-angle, but also to chaos and uncertainty. I broadened and opened my mental outlook sufficiently that, in time, I was able to become a software designer. I would’ve been too rigid otherwise; the Gods know what career I might’ve ended up in.

I have remembered this decision maybe half a dozen times in my life, but only this last time did I give it any serious thought. I have no idea what prompted it. It may have been something somebody said, or something I heard on the radio or TV. I have even toyed with the idea that it never happened at all, that it is just a reflection of my mental growing-up, as I began to entertain notions that didn’t originate with an adult. It seems possible, but I don’t think so….

The memory seems real to me. The effects of my actions enabled me to listen to (and enjoy) Indian singing, which uses notes that Westerners typically hear as dischordant. That’s just an example, but it illustrates the importance of the change in me as I sought out the beauty of asymmetry, and similarly scary concepts.

I would not be – not even in the smallest way – the man I am today if I had not had this realisation, and done something about it. Having spent a few days wondering, the most interesting thing (to me) is whether this really happened, and when. I think it did. By ‘feel’, I estimate my age to have been 5 or 6, but I don’t really have a clue.

P.S. One thing I am sure of: when I first had these thoughts, I did not think of them using the sophisticated and mature terms that hindsight gave me to write the above.

My most life-changing decision

Firmware – the tunnel at the end of the light

I think we have reached a point where the demise of firmware is clearly visible. It’s quite a way away, but now is the time to start planning.

Let’s be clear. If you still dream of 64k of contiguous RAM for your (application + RTOS + stack(s) + heap), then you write firmware. If your target hardware comfortably exceeds this, you write embedded software. [I know these terms aren’t universally agreed or understood, but this is how I’m using them.]

These days, fast 32-bit micro-controllers are available cheaply; RAM is the main limitation on what we can do with them. As the amount of RAM in micro-controllers increases, it will reach a point where they can support embedded software.

Embedded software is more mainstream than firmware. Applications run under grown-up OSs like Linux or Android. And they’re coded in modern languages that firmware target platforms can’t yet support. Like much modern software, embedded software is largely independent of its target hardware. It’s a different world.

When affordable micro-controllers can support embedded software, the need for firmware will start to decrease. Eventually, firmware will become a backwater, a small one. Before this happens, we firmware designers need to have expanded our skills into embedded software.

This means that we must embrace software design to a greater extent than we have in the past. Embedded software is less tolerant of, er, laxity than our smaller and simpler firmware designs. And embedded software is where the future lies. It’s what the tunnel in the title of this post leads to.

Today, firmware is a thriving discipline, and this will continue for some time. It will take a while before on-chip micro-controller RAM reaches the threshold needed to support embedded software (256k? 1M?). But when it does, the transition will be rapid, I think. Firmware will become a maintenance occupation. In my experience, many firmware-containing products stay in the field for ten years or more, sometimes a lot more. For as long as these products are supported, there will be a need for firmware designers.

So the end of firmware is visible, on the horizon, and we have years to prepare. Any improvement we decide to make in our design skills will benefit our firmware in the short term, as well as preparing us for the future. So this post is not a woe-ridden ‘the end is nigh!‘ sort of thing. It’s more like: forewarned is forearmed.

Firmware – the tunnel at the end of the light

The Guidance of Goldilocks

We are often advised to include just enough of this or that in our designs. It’s good advice. It doesn’t teach, it just reminds us to optimise, well, everything. Our development environments can often benefit from a substantial dose of just enough. Our designs too. Documentation. Our tools and methods, and how we use them, often cry out for some just enough. And don’t get me started on processes!

Take architecture as an example. Every design needs just enough architecture. Because projects vary in just about every way, just enough architecture for one is too much for a second, but too little for a third. Just enough architecture is the right amount of architecture for the project in question. It’s not a fixed thing that can be codified, followed and forgotten. Optimisation is a dynamic and continuing process. You need just enough of it, of course. 😉

Everything Goldilocks chose was ‘just right’, or just enough, in our parlance. This also embraces “Make things as simple as possible, but not simpler” (usually attributed to Einstein). I.e. Employ just enough simplicity.

Desperation can lead us to take a crude average and call it an acceptable compromise. Goldilocks is no such thing. It advises us to employ just enough up-front design, which is to say, the right amount of design. Given that this advice is offered to designers, it reduces to “Do your job right”. This is good advice, but a designer will do this anyway, so it’s a null command. This is why we stick with the phrase “just enough”. It means the same, but it evokes the spirit of the Einstein quote. It reminds us that too much design is sub-optimal, and too little design is sub-optimal too. Specifically, it tells us there is an optimum amount of design, which we should discover and apply. This optimum amount is not a theoretical chase after the perfect design (whatever that is). It is a practically achievable aim.

Repeat just enough to yourself at least once daily. But don’t restrict it to the amount of up-front design you should apply. Your design needs just enough documentation. The documentation should contain just enough detail, with diagrams that contain just enough information to maximise clarity. Your code needs just enough unit-tests to meet your needs. And so on. The Guidance of Goldilocks applies usefully at all levels, throughout your development environment. So, although it reduces logically to nothing, it still offers something useful. Good, eh? 😉

Porridge, anyone?

The Guidance of Goldilocks