Embedded software engineering priorities – a response
I am always interested in receiving feedback and comment on my blog posts and, when I recently wrote about embedded software engineering priorities, I did receive some interesting responses. When I get some useful input, I commonly ask permission to publish it. Sometimes this is refused, but usually I am given leave to post the comments.
In this case, the comments are, IMHO, quite controversial …
The person who made these comments asked not to be identified – a wish I am happy to respect. Here is what they said:
I saw your recent blog about the outcome of asking embedded software engineers their priorities. Like you, I too would have easily predicted that “3. the tools” would have won Jim Turley’s survey, but (apparently) for an entirely different reason.
In my experience (and believe me, this is very narrow despite 14 years in this field professionally) I have always noticed that most hard-core Linux developers prefer the command-line and, as a result, develop an excellent relationship with their tools (they tend to be experts at using vim, emacs, gcc, make, ld, etc). These cmdline people seem to be quite rare, and are getting even more so.
Meanwhile, most microprocessor developers (those developers primarily working with 8/16-bit or low-end 32-bit processors) I have encountered cling to their GUI-based Windows-hosted IDEs, scoff at any mention of a cmdline, have no idea how a compiler differs from an assembler, are oblivious to the existence of linkers, and wouldn’t touch a Makefile if their lives depended on it. These seem to be the growing trend and the majority.
What amazes me is, these (clearly) aren’t dumb people. They will happily study 1000+ page data sheets and pore over dozens of schematic diagrams for days on end… but ask them to learn gcc on the cmdline? Forget it!
My interpretation of what you said in your blog post is that developers chose their tools over everything else because they develop meaningful relationships with them the same was a master craftsman would with their tools. My interpretation of the results of Jim’s survey is that these IDE-type developers have developed a dependency on their IDE tools and quickly become lost when things change because they lack the fundamental knowledge of what goes on behind the scenes and, frankly, don’t apparently care to learn.
I have to say that my observations are somewhat different. In my experience, an embedded software team is quite a diverse bunch. The “systems” guys, who are comfortable working close to the hardware, also like to fully understand their tools and know how to configure them optimally. On the other hand, “applications programmers” are not too concerned about the execution platform and, hence, have little interest in the finer points of tool configuration.
Does anyone want to take sides? Please email or comment.
