Embedded Developer's Survival Guide, 2005

An anonymous reader writes "LinuxDevices has published the full keynote address delivered at the Embedded Systems Conference 2005 by Wind River CEO Ken Klein. The hardnosed speech presents a five-point action plan for device software developers who are interested in keeping their jobs -- as opposed to becoming "roadkill," as Klein puts it. The speech is decidedly short on warm fuzzies, but does offer a few practical considerations for engineer job survival in the post-recession era."

Comments

Article summary

[p3d0]

Suits to coders: stop whining and work harder.

summary

[klossner]

It's all pointy-haired boss stuff. Starts out with an incorrect premise:

We [engineers] don't do development well: More than half of embedded designs are completed 3-4 months behind schedule; 24 percent -- nearly a quarter -- get cancelled

In my twenty-mumble years of engineering, pretty much every time these problems have occurred it's because the requirements were changed in mid-project. Often for excellent reasons, but the consequences do not reflect an engineering deficiency.

Don't write new code, leverage existing software. Buy it from us.

Hardly unexpected.

Re:summary

[rjshields]

It's all pointy-haired boss stuff.

Quite so. I find it hard to stomach what this guy is saying - first he purports that he is one of us engineers because he has a science degree, then says he has 500 people reporting to him and sits on a board. Which is it? Suit or techie? Suit, obviously. Then he has the gall to proclaim that it's the engineers' faults that 30-40 percent of projects fail. IMHO the following factors are most likely to cause a project to fail:

• Poorly defined requirements
• Bad project planning
• Bad project managment
• Scope creep

None of these are in the remit of the engineer. The engineer is the guy who gets the job done by doing what he is told. If the person doing the telling is useless, what chance does the project have?

Re:summary

[DrZombie]

A browse through McConnell's "Code Complete" gives a fairly good synopsis of why a lot of projects fail, and it usually has to do with upstream work. Business requirements, system requirements, architecture. These things all have huge impacts further down the line, especially when they have problems. The cost analysis in the book is enough to scare any managers with an ounce of sense into putting some more work in at the front of the project. On another note, I'm curious how to get into the embedded development field. I have a degree in CS and a lot of work experience writing software systems, just not in that area.

What practical considerations?

[mutterc]

I actually RTFA, and didn't really see any practical considerations. It's written by a boardroom type, and so all it has is the usual management drivel we all get every day:

• If you get laid off, it must have been your own fault for not keeping up with management's desires.
• Make sure to change to whatever job management wants you to do, without complaint.
• Don't be threatened by outsourcing; learn to manage the contractors. (Because, of course, every engineers secretly longs to be a project-manager, and there will be plenty of PM jobs to soak up all the unemployed engineers...)
• The CEO's job depends on your doing your job well. (Curiously failing to mention that, if the CEO loses his job, a golden parachute kicks in, he cashes out a buttload of stock options, then finds a new job without much trouble - none of which is available to us).

It never ceases to amaze me how companies try to hire people smart enough to develop good products, and then expect them to fall for such transparently self-serving bullshit.

Maybe instead of the article's suggestion of "don't take change personally" (really!), I should learn to not take insults of my intelligence personally. If only I could mod the article "-1, Troll"...

Re:What practical considerations?

[computational super]

You forgot to mention:

• Your "technical skills", although they were the ONLY thing we looked at when we reviewed your resume and the ONLY thing we talked about in your job interview and the ONLY thing we discuss in annual reviews, are completely meaningless; we could replace you with a poorly-trained monkey because it's your "people skills" that matter. In other words, you have to be able to do my job for me AND an engineer's job. I, luckily, only have to be able to do my job. And you'll be doing that for me anyway. Plus, you'll still be the one on the unemployment line, and the years you spent doing my job will stagnate your "technical skills" so that nobody else will even look at your resume.

Politics-Oriented Software Development

[cpeterso]

The alternate viewpoint to this article is given by Kuro5hin's "Politics-Oriented Software Development". That article includes advice and insights such as:

• Most software fails because it is designed to fail
  
• Make sure architecture assigns blame clearly
  
• Managers don't want to know the truth: keep it from them.
  
• Overtime only counts when people see it