3 ms·

A mix of technological and cultural path dependence, cowboy attitude to performance/optimization, and inability to quantify risks. (Somewhat interrelated, eg c

by zurn 13y ago

A mix of technological and cultural path dependence, cowboy attitude to performance/optimization, and inability to quantify risks. (Somewhat interrelated, eg cowboy attitude -> C, path dependency in C usage -> hard to reason about programs -> hard to quantify risks)

pjmlp 13y ago
I liked your "cowboy attitude -> C". Everyone is a C expert, except when they happen to be a tiny cog in a big coding machine. "I know where all my pointers are memory allocations are!". Sure, but does everyone on your 20+ people team from the intern up to the senior guys know? Then things like this are bound to happen.
sfk 13y ago
C is used in such applications precisely because it is one of the few languages that allow you to reason about things like stack usage. Try that in Python, Ruby (or ML for that matter).
diydsp 13y ago
This. I've done consulting in embedded for years and years. The discipline of modern desktop/web development has not reached the embedded world, except in a few high-margin areas (such as military and transportation). There are 1,001 reasons for this, ranging from people who didn't learn source control, open source and unit-testing doing much of the coding (iow people from other disciplines besides software engineering and people who don't keep their skillset current), to the fact that cross-compiling is much harder/slower to debug than workstation debugging to the fact that resources are more limited in embedded, so code is more terse, with fewer convenient debugging functions. Other problems are with management- they see embedded code as a "write it and forget about it" schedule item, not a continuous improvement one. Much of this is due to the fact that embedded code is not as portable as workstation code. All of these shortcomings sufficed when the number of time pressure of embedded projects was much smaller 5-10 years ago. Now that embedded has exploded in ubiquity, its requirements are increasing and it's getting less time to be perfected in most markets. So yeah, I guess it's safe to say the embedded world is in a bit of crisis at the moment.
- seren 13y ago
  Having work in a similar environment, I know at least one company where most managers have a hardware/electronics background, because their product was mostly HW when they started to work 20 years ago. But now, the split is more akin to 80%SW/ 20%HW and they are managing SW developers without having much idea of what SW development consists of. I know at least of one example of a top engineering manager not understanding what version control was : "Please merge all the features but not the bugs from branch X". (Which is a noble goal in itself, but might be hard to attain !)
- vonmoltke 13y ago
  > The discipline of modern desktop/web development has not reached the embedded world, except in a few high-margin areas (such as military and transportation). My experience is that it hasn't penetrated very far there, either. Sure, we had version control and code reviews. The process was so warped and bastardized from industry standards, though, that it became a CYA/box-checking burden to keep the SQAs who really didn't understand code happy than a tool to improve development. Plus, most of the managing and systems engineers were hardware types[1] who didn't really understand what the software groups were doing or how they operated. [1] Important note: I'm a hardware type, too. I'm just a hardware type that actually got and wrote software. Made the situation doubly frustrating.

by zurn 13y ago

pjmlp 13y ago

I liked your "cowboy attitude -> C". Everyone is a C expert, except when they happen to be a tiny cog in a big coding machine. "I know where all my pointers are memory allocations are!". Sure, but does everyone on your 20+ people team from the intern up to the senior guys know? Then things like this are bound to happen.

sfk 13y ago

C is used in such applications precisely because it is one of the few languages that allow you to reason about things like stack usage. Try that in Python, Ruby (or ML for that matter).

diydsp 13y ago

This. I've done consulting in embedded for years and years. The discipline of modern desktop/web development has not reached the embedded world, except in a few high-margin areas (such as military and transportation). There are 1,001 reasons for this, ranging from people who didn't learn source control, open source and unit-testing doing much of the coding (iow people from other disciplines besides software engineering and people who don't keep their skillset current), to the fact that cross-compiling is much harder/slower to debug than workstation debugging to the fact that resources are more limited in embedded, so code is more terse, with fewer convenient debugging functions. Other problems are with management- they see embedded code as a "write it and forget about it" schedule item, not a continuous improvement one. Much of this is due to the fact that embedded code is not as portable as workstation code. All of these shortcomings sufficed when the number of time pressure of embedded projects was much smaller 5-10 years ago. Now that embedded has exploded in ubiquity, its requirements are increasing and it's getting less time to be perfected in most markets. So yeah, I guess it's safe to say the embedded world is in a bit of crisis at the moment.

seren 13y ago
Having work in a similar environment, I know at least one company where most managers have a hardware/electronics background, because their product was mostly HW when they started to work 20 years ago. But now, the split is more akin to 80%SW/ 20%HW and they are managing SW developers without having much idea of what SW development consists of. I know at least of one example of a top engineering manager not understanding what version control was : "Please merge all the features but not the bugs from branch X". (Which is a noble goal in itself, but might be hard to attain !)
vonmoltke 13y ago
> The discipline of modern desktop/web development has not reached the embedded world, except in a few high-margin areas (such as military and transportation). My experience is that it hasn't penetrated very far there, either. Sure, we had version control and code reviews. The process was so warped and bastardized from industry standards, though, that it became a CYA/box-checking burden to keep the SQAs who really didn't understand code happy than a tool to improve development. Plus, most of the managing and systems engineers were hardware types[1] who didn't really understand what the software groups were doing or how they operated. [1] Important note: I'm a hardware type, too. I'm just a hardware type that actually got and wrote software. Made the situation doubly frustrating.