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

Roadkill!

[HogynCymraeg]

First PoO-O______

Re:Truly Enthralling Reading

[mosabua]

I agree. A very highly motivating article/speech. I found it especially interesting how he focuses on platform agnostics. Run anywhere...

He lost me here:

[Anonymous Coward]

The first thing I want to know is, how many of you in the audience actually are engineers? Let's have a show of hands.

Why didn't he ask how many people in the audience are left-handed? And did he mean an actual P.Eng or an engineering degree?

Re:He lost me here:

[Anonymous Coward]

Oh please, skip the P.Eng. talk, I am sick of it, and I think I am not alone on that one either.

Where is this described in Eclipse site?

[Anonymous Coward]

OK ... so where is the "Eclipse Device Software Development Platform Project" described?

I can't find that on the Eclipse site.

feh

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

[rjshields]

This guy is trying to tell techies how to do their job. How many developers do you know that enjoy re-inventing the wheel just for the sake of it? I know none because we're all lazy. And laziness is a virtue because it means we don't re-invent the wheel. The cheek involved in this guy assuming he knows how a developer should be doing their job better than the developers themselves is astounding.

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.

Re:Truly Enthralling Reading

[cpeterso]

Maybe embedded developers are:

1. too busy working to read Slashdot
or 2. too unemployed or broke to afford internet connectivity

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
  

Re:Truly Enthralling Reading

[BruteFarce]

I would agree that it was an interesting article/speech, so I am also puzzled at the relative lack of comments. The tone of the speech was a bit depressing, from a developer's perspective, but I think that the unvarnished truth has that tendency. He seems to be saying that embedded software development is going to be both harder (more challenging) and less fun (in the sense that survival will be more about the non-technical stuff). On the more positive side, if people take his advice and stop reinventing the embedded wheels, they will have more time/money to invest in interesting applications of those reusable parts, so perhaps the glass really is half full here.

Here is a link for you

[p3d0]

Irony.

Re:Truly Enthralling Reading

[Doc Ruby]

Actually, most of the comments in this thread (many of which were posted after yours) point out that the speech was a harsh message to improve quality, from an exec posing as an engineer, blaming engineers for quality problems really originating elsewhere in the development chain. And therefore the responsibility of management, especially execs like him.

To me, it looks like he's fantasizing about quality improvements from moving engineering work overseas, where labor is cheaper. Execs often think the less "privileged" labor will "follow orders" better, but American engineers are generally more disciplined, *per dollar paid*, than their foreign competition. And executive jobs aren't nearly as safe from foreign labor competition as execs usually believe.

Re:Truly Enthralling Reading

[rjshields]

I'm guessing it's a phsychological phenomenom whereby the majority of /. readers read the teaser and have a sudden bout of writer's block.