From time to time, a developer asks me "How can I convince my team/manager/organization to ..." - and after a brief discussion with followup questions, I often answer "you can't convince them".

Let's let that sink in.

There are many reasons why convincing someone that your awesome idea is worth pusuing is harder that you might think. It often has less to do with your idea, or your presentation, and more to do with how the folks around you are motivated and measured.

Let's let that sink in too.

There are a few basic truths about why it's hard to implement change that have almost nothing to do with the quality or substance of the idea - so let's dive in.

Read more…

Even if you haven't seen "2001: A Space Odyssey", you have probably heard someone say "Open the pod bay door, HAL".

"I can't do that, Dave" is a familiar feeling for embedded systems developers when your hardware isn't doing what you think it should.

By now you might have guessed that this article is about how having a HAL (Hardware Abstraction Layer) for your embedded system makes your life easy, changing to a new CPU is fast and painless, and the kids all get ballons and ice cream when your port takes only hours because of your awesome platform approach.

The reality is always different - what started as a simple port is now a bit more complicated because a new RTOS is mandated, and there are new security requirements, and the interface to expander boards is different, and so on.

All of a sudden, the HAL is the least of your problems because on top of the architectural changes, you don't have any kind of unit test framework or continuous integration system to help you move forward with confidence.

Take heart - this is the perfect time to get all of that stuff in place with a small and focused team. And you can take advantage of the fact that you don't have any hardware yet to get these critical building blocks in place.

Let's find out how to approach this starting with the HAL ...

Read more…

Misson statements. Hands up for anyone who loves their company mission statement.

Hands up for anyone who knows their company mission statement.

In many organizations, the mission statement is laid out by top level leadership, sometimes with input from departments or individuals. It tends to be a general and somewhat fluffy set of words that could apply to just about any organization. And that makes most mission statements forgettable.

That doesn't mean your maintenance team should not have a mission statement! Your job together with your team is to come up with a statement that reflects how you want to be seen and heard within the organization moving forward.

Read more…

Your department has undergone another re-organization because ... actually it doesn't matter. The goal was to step-change the innovation culture so that your company can quickly deliver world-class experiences that delight your customers and exceed their expectations.

Sound familiar? Depressingly familiar? Wasn't this supposed to be one of the outcomes of the last reorganization? What happened?

First, take heart. Leadership doesn't wake up one morning and decide on how to make things worse. There is a genuine desire to make things better - what's missing sometimes is asking the hard questions that drive change in the right direction.

Let's have a look at why innovation is so hard to achieve in some business environments, and what we can do to turn things around. This is definitely not a list of "5 Easy Ways To Innovate" - it's more about taking stock of where your organization is today, and deciding on the first steps towards where you want it to be.

Read more…

You've been working for hours to figure out why the system you have delivered fails very occasionally.

You have good bug reports that show it takes about 25 days of continuous run time for the failure to occur, and it's happened at 4 different sites now. You get a spidey sense that it might be related to a timer and pull out your phone and fire up Free-42 (because you like RPN calculators). The math for a 1 msec timer interval says that a 32 bit unsigned int should be good for about 50 days ... wait a minute. The restarts happen about 25 days apart!

You find the place where someone did a calculation with the clock using signed instead of unsigned values, and mumble "I wish that we had a coding standard to catch this".

Said nobody. Ever.

What you really needed was a Developer's Guide for this project, a test-driven development mindset, and a review process that could work together with continuous integration to have a better chance at catching the problem.

Of course the title is designed to catch your eye, and a coding standard is not a bad thing. Just pick one that's already out there like the Linux Kernel or MicroPython coding standard and call it a day.

Read more…