Is pair programming for the embedded folk?

I just read an article in Obbie Fernandez’s blog about pair programming and how it is not for every company (10 Reasons Pair Programming Is Not For the Masses). I don’t usually read his blog cause I’m not a web developer, but my brother (who does do web development) tweets the articles he likes and I read them…(except when they talk about high level ruby code that my lowly embedded-C brain can’t or doesn’t want to understand).

Aaanyway, pair programming has always been something that intrigues me. The article basically states why it is difficult for most development teams to adopt the pair programming method. It just requires too much commitment and so much non-traditional focus that most shops are just not ready to do it. Even so, I bet there are embedded software companies out there willing to try the model out and that actually have the resources and commitment to make it happen. This leads me to (dreamily) wonder, is embedded software development adequate for pair programming? Most of my reasoning points towards yes, embedded software is, for all purposes, software, so the model should work even if it is not the ideal world of web (for more on why pair programming is so good for the web software folk, read this article by Rod Hilton). I felt particularly devastated by “the no-asshole rule” cause, let’s face it, the embedded development community is full of these types (all of them, the prima donnas, the smelly ones, the antisocial ones).

I also see a big problem with the overall maturity of the embedded software industry. From my very personal point of view, there are currently two types embedded software shops:

• The stick-to-the-process, extremely formal type of place: these are the places where they are making really “important” software, for example: automotive, aero-space or networking (some) industries would be here. These types of shops have a rigid process and way of doing things all focused on clearing all sorts verification, validation and tests. Would they be willing to commit to the big change that would be jumping to a pair programming model?
• The rest: sorry for the ambiguity but most other shops (again, from my perspective) are just completely random, with all sorts of people following all sorts of processes and/or not following any at all. There are of course varying degrees of truth to this, but the fact is that as an industry, we are way behind in jumping to an actual “software engineering” culture, most people come from an electronics engineering background, which doesn’t help either, and most of the people don’t really know or care about the benefits of formal processes (and I’m not talking about the IEEE, RUP, ISO type thing, but just a set of light and easy-to-follow steps like requirements-architecture-design-code-test). In this (admittedly) gruesome and negative panorama, does it even make sense to throw in a paradigm changing model? Not sure.

What do you think? Are embedded developers mature enough to pull pair programming off?