• some guy (unregistered)

    Can someone tell me what a "flash validation" is? Running the software on the actual hardware as a smoke test?

    Also, mandatory: https://xkcd.com/2030/

  • 516052 (unregistered)

    I've always purposely avoided jobs where my screw-ups might produce serious injury or death.

    What turns me off jobs like that is that they always come with strings attached. We are talking high pressure, tight deadlines and annoying red tape all over the place. When you combine corporate greed with insistence on quality and safety by regulators there is only one way things can turn out. Nobody is ever going to give up part of their profit margin to make your life as a dev easier.

    This said, if someone had offered me a laid back and non high stress job in such a field I'd not have said no. At the end of the day bugs will happen, and on occasion people will die. That's just how it is. No sense stressing over that. And if it's going to happen to someone it might as well be me. As long as nobody can sue me personally over it and the whole thing is not some sort of obvious idiot mistake on my part I'd not feel any guilt over an airplane or ten falling out of the sky because an unforeseen bug.

  • G. Gekko (unregistered)

    But think of all the shareholder value generated. The product is just an annoying afterthought.

  • (nodebb)

    The thing about engineering in the real world is that it has evolved over decades and centuries, depending on what's being designed. We've been creating buildings for millennia, and we've increased size and complexity incrementally, building on what previous architects learned. Airplanes are only a little over a century old, but still that's been time enough for us to learn the basics and improve on them. Early planes probably fell out of the sky all the time, now crashes are rare and almost always due to a really strange glitch.

    Software has the problem that each new application is almost starting the evolution process from scratch. While past software engineers may have solved some fundamental problems, like memory management, the domain-specific parts are new. Just as you can't apply too many skyscraper architecture principles to designing jumbo jets, what we've learned from designing word processors doesn't help much with cockpit automation.

  • (author) in reply to some guy

    That's what it sounds like for context. Flash the software onto the device, power it up, and see if it works for a very minimal test of "works". That "working test hardware is scarce" implies that you may fail this validation not because of software failures, but because the test hardware you're running it on is busted. I've been in this state- tracking down bugs in software when it's just that one of the pins on a board got shorted at some point and now the board is wonky.

  • (nodebb)

    Ah, yes. The wonderful "We have a schedule to meet" on what everyone except the C-suite and the sales dept knows is still an R&D project.

  • (nodebb)

    If Greta's organization isn't following some form of NASA/JPL's "Power of 10" coding standards for safety-critical code ( https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code ) and its extensions ( https://nasa.github.io/fprime/UsersGuide/dev/code-style.html ), then they should be...

  • (nodebb) in reply to Barry Margolin

    That's because software is fundamentally different from other types of engineering. If you build a successful bridge or house and you want another, the copy is made of different substance and likely built by different workers under slightly different conditions. But if you have a successful piece of software and you want another copy, copying it is trivial. You can be absolutely certain that the copy is identical to the original, so all software engineering is doing something novel.

  • (author) in reply to Charles-2

    I think that's a misunderstanding of how large engineering projects are carried out. If you build a successful bridge, and want to build another one, you're usually starting from square one. You can't just copy the design, because the actual geography is going to be different. Adding a few feet to the span might make no difference- or it might change the tolerances such that you need a totally different design. And there's also a constant race to improve- to use fewer materials, to get it built in less time, etc. (Just the fiendish challenges of adapting a design to the regionally available concrete can be a huge undertaking- concrete is different everywhere you go, and it's only cheap because there's usually a local source for it; shipping in concrete would defeat the cost savings of concrete!)

    Houses, especially the tract-style developments, definitely are more in the direction you're saying, but also- they're not engineering. Or the engineering happened years ago, and now it's built-to-plan. But that's because they are, relatively, a mass-produced widget.

Leave a comment on “The Ghost of Christmas Future”

Log In or post as a guest

Replying to comment #688879:

Log Out

« Return to Article