Help Us Embedded Software Developers… You’re Our Only Hope

Agile2011 will be my first time talking to crowd of embedded software developers. I already know tossing my hat in the ring has been a good idea because the whole experience has me thinking from a different direction. I’m starting to see the necessity of better collaboration between hardware and embedded software experts on SoC development teams, but it didn’t really gel until I started thinking in terms of system functionality and usability.

I’ve used this slide with a generalized design flow once before with a mishmash group of software developers to illustrate how our respective disciplines tie together. It’s a 5000ft view of an SoC development meant to show how we work on two different ends of the development spectrum.

We hardware developers live down in the weeds. We see things like gates, counters, filters, packet transformation, the details of an interrupt mechanism and pin-level communications protocols. Our deliverables are normally captured in a hardware specification and our job is to build the hardware such that it’s functionally correct before it’s taped out. We are not users nor do we have much direct contact with users so the concept of functional correctness is probably the best we can do.

Software developers are at the far end of the spectrum. Gates and pin-level protocol mean nothing to them. Their job is to take the hardware we’ve given them and make it usable for our customer.

A potential problem with this situation, in case you haven’t seen it yet, is that hardware that’s functionally correct doesn’t necessarily translate to hardware that’s usable. We hardware developers can stew over clock-by-clock details that have zero impact on the system, while at the same time brush off details that can cause head-aches for software developers or even cripple the system entirely. Corner cases for us can be primary functionality for them.

So how can we close the gap between functionality and usability? I think there’s work to do on both sides of the fence.

Embedded Software Developers

Get involved early with the design of the hardware and stay involved

Help your hardware teammates think in terms of system-level usability

Include hardware developers in customer correspondence and see that issues of usability are broadcast to the entire team

Develop software as the hardware is being developed so that your feedback can be used to tune the hardware

Hardware developers

We aren’t users so it’s difficult for us to think like users. Realize that in terms of usability, we generally don’t even know what we don’t know

Help your software teammates understand the possibilities and limitations of what you can do in hardware

Work together with software developers during design and implementation of APIs instead of guessing what software developers might need or waiting for them to tell you

Supply software developers with early prototypes or models to enable early software development

Don’t optimize hardware without considering the impact on the software

Management/Leaders

Treat hardware and software developers working on the same SoC as part of the same team

Ensure hardware and software teams are co-located (or at least partially co-located) so communication is productive

Use a common reporting structure for hardware and software developers to avoid personnel conflicts

Enable and strongly encourage co-development of hardware and software

All these are things I thought of while putting together my Agile2011 talk. I like the functionality and usability labels to emphasize that the focus of hardware and software experts is fundamentally different. I’m hoping bringing functionality and usability together underscores the critical importance of early collaboration with software developers. They understand the system and interact with users in ways that we don’t.

Considering everything they do know with everything we don’t, if we plan on having happy customers, they’re our only hope!

Great post Neil. You might find this difficult to believe, but my experience is that the hardest thing to change is “getting folks to treat hardware and software developers as part of the same team.” This fundamental shift often needs to start much earlier than when the teams are forming. For example, I find that the initial strategy (go/no go) decision before a project is launched pits a hardware development leader against a software development leader competing for a slice of the same funding pie. If this is how the project starts – two separate R&D teams competing for $ – the relationship is difficult to mend from there on out.

catherine. thanks for pointing that out. that’s a level of negotiation that most developers, I expect, wouldn’t even see. This is a fundamental shift then… teamwork starts even before the teams get involved!

It’s a good summary. More communication at early stage yield a better product. Sometimes SW doesn’t know if some feature is low cost in HW, and sometime HW try to implement some things on not a time critical path which are better to go in SW.