|
|
|
|
|
|
by constantcrying
695 days ago
|
|
|
>So much of software today controls hardware that may end up controlling (insert your deadly item here: life support, airplanes, cars, trains, critical infrastructure, deadly infrastructure, etc) that it makes me wonder just how much holistic testing of the "in which ways can this software fail and kill people" has taken place. For aerospace software specifically, a lot. Embedded Software Developers also are often people who also are Electrical engineers and understand how to do proper engineering of a system. In aerospace you have very specific guidelines on how software is developed and tested and which tells you what you need to consider during/before/after the development process. As is common in engineering the "doing" part (e.g. writing the software) is the least relevant part. |
|
|
I'd wager 60% of software engineers work on teams where they have an existing product, add a feature, and then when done go add a new feature. A sizable % of this folks so have other teams working on other parts of the same codebase. Development is incremental, with no long-term vision, and certainly none of the hard metrics for success.
Speaking to the parent, we had a couple weeks of engineering ethics in our computer engineering undergrad. The dude railed on software for having defects, for being at a crisis point, and I threw back super hard & continue to think that most of the field has to face down enormous combinatorial complexity of inputs. And we have to work against moving target codebases where our added work is typically dwarfed by existing complexity. And unlike a bridge or a floor, there is very little opportunity to overbuild against specifications. We can't shoot for 130% of expected load (in most circumstances), it works until it doesn't.
Thankfully I feel like most mission-critical devices tend to have more limited missions, aren't so open ended, but most software development feels more like an ongoing effort to keep iterating and adding than an cross-the-finish-line effort. Every sprint should be at least one release right? How do we get such high assurances in such regular repeated development cycles?