In response to comments made on Embedded.fm episode 114 (Wild While Loops), an electrical engineering listener emailed us:
We all know that ‘throw it over the wall’ sucks as a business pattern. But it’s sometimes really hard not to; I’ve recently been under pressure to order those new boards already. Or I’ve flat-out overlooked something. Or I misunderstood how much testing the last guy had done. Or whatever. It’s hard.
We know we shouldn’t just throw and run, but it’s hard. Do you have any thoughts on how to persuade my boss that stronger reviews, and getting the embedded software people in on them, are a good idea?
I recognize that “throwing over the wall” between hardware and software is somewhat inevitable, especially as HW and SW sometimes have different schedules. The difficulty comes in when there is also animosity: the EE says the problem is software, the SW says it is hardware; no one works on it because it is clearly not their bug (or works on it resentfully). I remember those days and am very glad I grew out of it.
But how to persuade your boss more reviews (and possibly earlier reviews) are worthwhile? If your boss is a promoted engineer, data might help. How many issues were found and by whom? (That person could be part of the reviews.) How many hours do the SW folks say were lost to HW difficulties (that includes schematics they didn’t understand)? How much will a board respin cost if a problem isn’t identified until a quarter of the way through the software schedule? (Even better: how much did the last respin cost in terms of money and time lost?)
You might also pitch better reviews as cross training: should you win the lottery and go on a bender, a cross trained embedded software person might be able to babysit your work for a couple weeks until you sober up or another EE is hired. (We used to say “get hit by a bus” until my EE actually did; now I try for more positive scenarios.)
I am quite thankful that HP believed in cross training. I know the EEs didn’t get a lot from my review of their schematics (“Can you rename this net because I don’t understand your vernacular?”) but I sure did. It made me more effective in my firmware job because I knew what their plan was. It allowed me to debug with an oscilloscope by myself because I understood the schematic before I had to use it (before I was deep into “there is a problem!!!” mindset). Plus, I could ask for the test points I needed instead of cursing the lack of available signals.
And, of course, it is hard. Not only is the work hard, the boards and code are personal expressions of our brains making criticism difficult to accept gracefully. And engineers often neglect to turn on their niceness modules. And schedules are brutal. There is no time for reviews and it is hard to expose ourselves to the angst.
But you do the best you can and try to do work you are proud of, sometimes fighting the right battles, other times tilting at windmills because part of you knows it is important even when others can’t see it.
Hey, look, a rousing speech to close on.