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

  1. Get involved early with the design of the hardware and stay involved
  2. Help your hardware teammates think in terms of system-level usability
  3. Include hardware developers in customer correspondence and see that issues of usability are broadcast to the entire team
  4. Develop software as the hardware is being developed so that your feedback can be used to tune the hardware

Hardware developers

  1. 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
  2. Help your software teammates understand the possibilities and limitations of what you can do in hardware
  3. 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
  4. Supply software developers with early prototypes or models to enable early software development
  5. Don’t optimize hardware without considering the impact on the software


  1. Treat hardware and software developers working on the same SoC as part of the same team
  2. Ensure hardware and software teams are co-located (or at least partially co-located) so communication is productive
  3. Use a common reporting structure for hardware and software developers to avoid personnel conflicts
  4. 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!


When Done Actually Means DONE

In presentations I’ve given on agile hardware development, there’s one slide I have that seems to get the point across better than any other as far as how agile development differs from the waterfall-like process a lot of hardware teams follow. I’ve used it a few times before and I find myself counting on it again for my talk at Agile2011 in Salt Lake City.

In prior talks, I’ve built up to this slide with a verbal contrast between waterfall and agile. I talk about waterfall development as a sequential process that culminates with one big bang deliverable. Progress is tracked against a master schedule and based on what pre-defined tasks have been completed. The lessons learned at the end of a project are applied to the next project (i.e. you have a chance to improve once/project). I don’t claim that waterfall is exactly what hardware teams do, but it’s close’ish and the task based planning certainly does widely apply.

The agile model, on the other hand, is an iterative process where each iteration culminates in production ready code equivalent to some subset of the end product, meaning you can quit and release whenever you and your customer want. Progress is measured based on which features are complete at a point in time and lessons from each iteration are applied to the next (i.e. you have a chance to improve several times/project).

These are obvious differences, but the underlying message is never quite apparent until we get to the visual. That’s where people can see that the critical difference is in the definition of DONE.

Let’s say a team following a waterfall model is half done building an XYZ, which to the team means their design documentation is done, the design has been coded and they’ve built some of the verification infrastructure. Lot’s of good stuff there, but because the team has based its progress on predefined tasks they’ve completed as opposed to what they know actually works, half done can be pretty misleading. The documentation they have could be severely out-of-date, the design is probably somewhere between buggy and dead in the water and the verification environment might not even compile yet. Needless to say, the second half of the project is going to take much longer than the first half did!

Contrast that with the the definition of done in the agile model. Here, progress is based on features. When a team says “we’re half done”, they mean it. With little warning, they could release a product with half of the intended functionality. They know it’s done because it’s been tested, it’s been through the back-end, the software has been written and it’s ready to go.

Two different ways to measure progress; two very different meanings for the word DONE. To me, its this visual contrast with the waterfall and a redefinition of what it means to be DONE that helps the value of agile development really stand out.


Q. How do you measure ‘done’? Code that’s written or code that’s production ready?

Not A Problem… The “Fluffy Stuff” Isn’t That Important Anyway

There are 17 different stages at the Agile2011 conference in Salt Lake City that cover a wide variety of topics. Though there are obviously technical stages (it is a software conference after all), what would probably look odd to hardware developers browsing the program is the number of stages dedicated to the non-technical (aka: the “fluffy stuff”).

Yes, you did read stages dedicated to the “fluffy stuff”, not just individual sessions. The 5 that stick out to me are:

I know that these topics are important to agile developers so I wasn’t too surprised to see them. What did surprise me though is that not only are these topics covered at Agile2011, they’re well covered with an average of 15 sessions for each stage! Now, I’ve never been to previous Agile2xxx conferences, or any software conferences for that matter, so I know nothing of content and quality (both of which I’m assuming are decent). But by the simple fact that these sessions take up almost a 3rd of the program, the folks that put this on seem to think they’re worth the time and effort.

In another universe… could you imagine going to DVCon and seeing a track called Collaboration, Culture & Teams with 22 sessions? Would SNUG, User2User or CDNLive have a track called Coaching & Mentoring with 15 sessions. How about just 1 session? One bright light I do see is at DAC where they have a “Management Day” on June 7th. Other than that, topics stay pretty technical at all of the above. I list these conferences because they are reasonably accessible for the average joe and generally well attended. If there are other conferences I’ve missed that do fit the bill, I’d appreciate you letting me know.

I’ll venture a guess that the sessions I point out don’t get run at hardware conferences because we hardware guys don’t have much of an appetite for the “fluffy stuff”. Even though leadership is important, even though we could probably learn something by listening to how out peers work with customers, even though there are times when we need to coach and/or mentor colleagues, we probably rely more on what we’re born with and experience first hand than what we learn. Or maybe as a group we figure that technical excellence will compensate for lacking the “fluffy stuff”? Maybe we already know what we need to know! Who knows for sure.

It is hard to argue against the fact that “fluffy stuff” plays a tremendous role in hardware development. There’s no denying it. And we could likely get better… much better… though it seems we’re a little behind when it comes to realizing it!


Q: Got an opinion for why the agile software crowd spends so much time on “fluffy stuff” like leadership, coaching and mentoring while we hardware folks appear indifferent? I’d like to hear what you think!

A Better Way To Manage Conference Proposals

UPDATE: With acceptance emails going out for Agile2012 this morning, I thought it’d be a good time to re-spin this entry from last year’s run-up to Agile2011. If you substitute 2012 for 2011 and Dallas for Salt Lake City, I reckon everything else I had to say last year applies again this year. I like the process.

Special note for this year’s conference, Agile2012 will have 2 talks on ASIC and FPGA development. My proposal for “TDD And A New Paradigm For Hardware Verification” was accepted. As well, Tobias Leisgang from Texas Instruments had a talk accepted, How to play basketball with a soccer team? Making IC development more agile. You’ll find both on the Emerging Applications of Agile stage.

One hardware talk at Agile2011, two hardware talks for Agile2012… hopefully there’s a pattern developing here!

As I mentioned in a post a couple of weeks ago, submitting a proposal to Agile2011 was a last minute idea for me. I figured that since I had a collection of material ready to go, it wouldn’t take me long to put something together. I was almost right.

I’ll start by saying that the submit/review process for Agile2011 was about as transparent as I could have imagined. I’m used to writing an abstract, pulling together an outline, sending both away and then waiting for a yay or a nay a couple months down the road. That’s how SNUG generally works (I’ve presented 5 papers there… last in 2010) and DVCon as well (in 2010, Bryan Morris and I submitted a paper called Agile Techniques For ASIC and FPGA Development… it was rejected).

I’ve never had a problem with that, but the submission process for Agile2011 was different… dare I say better different… but I’ll let people decide for themselves.

The submission process was all handled online. Would be presenters login to write a summary of their talk in 600 characters or less, describe a set of “learning outcomes” (which I believe tells the audience what they should be taking away from the talk and who we think should attend) and finally the “Process/Mechanics” section which I think most people use to capture their outline. You also select a stage (of which there are several) where your proposal best fits. Here’s a description of the stages if you’re interested. I’ll talk more about them another time.

Pretty normal so far, except that all proposals are treated as proposals-in-progress so you can edit them at any time. They are also viewable by other presenters and anyone else who is interested, not just the official reviewers. I liked that. Seeing and discussing proposals before they’re accepted was something I wasn’t used to. I could contact other would be presenters to ask questions. We could also work together to avoid overlap. I’m guessing that makes for a better conference better by helping avoid repetitive material. We’ll see in August if that’s actually the case.

Also interesting was that there were options for session length/type. I believe there are 30min/60min/90min talks. There are also 3hour workshops and tutorials. Last are 10min lightning talks. Having different types of sessions is new to me, especially the workshops. Agile is supposed to be interactive so I’m thinking that the workshops end up being a conference highlight.

The best part though was that anyone could append comments to a proposal. That’s more feedback that I wasn’t used to and really appreciated. On average, each proposal got maybe a half dozen comments. From what I’ve seen and heard, comments were pretty constructive and helped would be presenters tune proposals over a number of weeks (mid-January to late march). All the comments I received motivated me to tweak my proposal. I’m guessing that most people ended up with proposals that were stronger than what they started with… I know mine was… so I’m pretty grateful to the people that commented.

From there, the official reviewers for each stage made their comments on each proposal after which I’m assuming they consulted with each other and the conferences organizers to decide which proposals were accepted.

Not an exact explanation of what happens but close enough.

Between the initial write-up, answering reviewer questions and revising my outline and summary, I spent maybe 4-5 hours on my proposal. Looking through what other people had, there are some that definitely spent more than that. There were also people that had 2 or 3 proposals… not sure where they found the time for it! I’m taking all the effort that people obviously put into their proposals as a sign that the prep time ends up being worth it 🙂

If you’re interested, you can take a look at my proposal for Applying Agile In IC Development… We’re Not That Different After All and the feedback it received (I’m excited that it was accepted to the Agile for Embedded Systems stage). Feel free to let me know what you think of it. You can find more details regarding how proposal are reviewed/accepted/etc in a write-up by Mark Levison on his blog. If you interested in seeing how Agile Alliance has things setup, you can go to

Neil Johnson

Lessons From A Software Conference – Part 1 of Several

Agile2xxx is a conference put on the Agile Alliance that has happened every year since 2003 (I think??). This year, roughly 1500 software developers from hither and yon will meet on August 8th at Agile2011 in Salt Lake City to hear colleagues speak, participate in workshops and discuss the next big things in software development. It’s not the only agile conference of the year but it’s a big one from what I understand.

I’ve enjoyed the opportunities I’ve had to present at conferences. But more so than at other conferences, Agile2011 is a chance for an experience that’s quite different. Why you ask? Well at hardware conferences, I talk to my peers–people that do the same things I do (which is mainly hardware verification). Acceptance and feedback can be mixed, but people normally get the gist of what I’m talking about. Compare that to me speaking at Agile2011.

  • Agile2011 is a software conference… I’m a hardware guy.
  • Attendees (I’m assuming ) are experienced with agile… me, experienced’ish.
  • Presenters (again I’m assuming here) are experts with agile… me, not exactly.

Hardly an exact fit. So why then would I submit a proposal? Admittedly, that was a last minute twitter-initiated decision.

Compared to agile software experts, I’d consider myself a rookie. A very enthusiastic rookie with decent experience but a rookie nonetheless. I have a long list of ideas for what should work in hardware development. I’ve done small scale rollouts of some of those ideas that have turned out successful. I’ve put a lot of time into it and because I’ve already given presentations and written about what I’ve been doing on, I figured I could cobble together a proposal relatively quickly. The submission process was an interesting experience. I’ll get to that in the next entry (spoiler alert: I did submit a proposal and it was accepted).

Back to the why… the first reason for me submitting a proposal to Agile2011 is to get expert opinions from others on what I think should work. I’m convinced that agile can work in hardware development, even though it is relatively unknown. I’ve seen it work on a small scale. The software guys use it so successfully that it’s ridiculous to think that we can’t use some of what they’ve already shown to work. The obvious differences mean it can’t be exactly the same, but the obvious similarities mean it won’t be entirely different either. Presenting my thoughts to a conference crowd gets ideas heard, critiqued and (hopefully) validated.

The second reason (which is where the title of the blog comes from) is that I actually intend to learn something from these strangers from the land of software! From the submission process to the preparation and the presentations, workshops, side discussions and everything else. It’s a different crowd and a different experience so I expect to be bombarded with great new ideas from a few different angles.

Finally, I would hope software developers listening to me talk about agile in hardware development will get something out of it also. If I didn’t think I could pull that off there wouldn’t be much point in me presenting anything!

Agile is big in the software community but relatively unheard of in the hardware community. I think has started to change that. I hope a presentation at Agile2011 is a good next step.

Stay tuned for the trials and tribulations 🙂

Neil Johnson