4 ms·

How is embedded development WRT requirements and process? I've had this theory for some time that a number of dev's frustrations are rooted in the fact that wh

How is embedded development WRT requirements and process? I've had this theory for some time that a number of dev's frustrations are rooted in the fact that what they're doing isn't anything close to real engineering. That for a great many of their jobs, quality is not really a priority because what they're creating could just as easily be gone or reworked tomorrow. So I've wondered if I'm on to something, do things get better the farther down the dev stack you go? Because, much like building a physical structure once that hardware ships the software is doing it's intended, required job. Sure, there can be firmware patches in the same way a building needs maintenance but it's not like management is going to recall the coffee makers because they think they should now tweet when your coffee was made.

shandor 8y ago
That depends the most on what you work on. Of course there is an abundance of embedded shops that do the kind of development that gets tweeted by @internetofshit On the other hand, things like heavy machinery control systems are usually in somewhere in the middle: the machines themselves are burdened by all kinds of regulations, and the machines can kill a dozen people easily by accident if something goes catastrophically wrong, so it would definitely suck to "move fast and break things". Also, like you mentioned, software updates are few and far between. Then there's medical and aviation and friends, where you have MISRA-C and the like. Very process-y, if you like that. Basically, work on SW for tangible things, and pick your poison regarding how much requirements and process you want. I'd say that on a very broad average, things do get more strict going farther down the stack, if for no other reason than that if the lowest level code does not work reliably, then nothing else usually won't either.
- metallurgy 8y ago
  I'd love stricter requirements. But the last thing I want is more process. I mean goddamn, I have to track work on our repositories, and our story tracker. I have to produce slideshows and excel docs and numerous other tasks which just exist to keep the MBAs happy. There's just so much bullshit work mixed into the actual task, not that I care much about the actual task in the first place.

shandor 8y ago

That depends the most on what you work on. Of course there is an abundance of embedded shops that do the kind of development that gets tweeted by @internetofshit On the other hand, things like heavy machinery control systems are usually in somewhere in the middle: the machines themselves are burdened by all kinds of regulations, and the machines can kill a dozen people easily by accident if something goes catastrophically wrong, so it would definitely suck to "move fast and break things". Also, like you mentioned, software updates are few and far between. Then there's medical and aviation and friends, where you have MISRA-C and the like. Very process-y, if you like that. Basically, work on SW for tangible things, and pick your poison regarding how much requirements and process you want. I'd say that on a very broad average, things do get more strict going farther down the stack, if for no other reason than that if the lowest level code does not work reliably, then nothing else usually won't either.

metallurgy 8y ago
I'd love stricter requirements. But the last thing I want is more process. I mean goddamn, I have to track work on our repositories, and our story tracker. I have to produce slideshows and excel docs and numerous other tasks which just exist to keep the MBAs happy. There's just so much bullshit work mixed into the actual task, not that I care much about the actual task in the first place.