10 ms·

What software developers should learn from the VW diesel scandal

4 points by di 11y ago

a3n 11y ago
N. Don't write any code that isn't specified by a requirement. In a shop as large as VW, there are requirements. Investigations are only beginning, but at this point it's plausible that some of the coders involved didn't quite know what the purpose of their code was. VW execs jumped early to try to hang this on "one or two software engineers." Promote this publicly in the interests of "traceability," which everyone agrees is a good thing. Want it privately in the interests of self-preservation. If a company wants something built, particularly in a regulated industry, they damn well better declare it. Which reminds me, it will be interesting to see how the VW code in question relates to their requirements systems.
- hydrogen18 11y ago
  Why do think VW would bother issuing formal requirements?
  - a3n 11y ago
    Because it's inconceivable that they could manage software and hardware production without them. They're huge. You can't ad-hoc something that large. Or are you asking why would VW bother with requirements for the cheating subset? Well, that would be my point then. Don't write software against something a manager mentioned in a meeting or in your cube.
    - hydrogen18 11y ago
      If we're talking strictly about an ECU, I'd guess that most of them are a codebase that is a complete disaster. The only management activity around ECU development is likely something to the extent of "6 engineers at 1.12 times our standard engineer cost for 6 months will cost us...". My guess is all of them just do shit until it works. There are tons of sensors, valves, etc. that need to be managed but it isn't anywhere near as complex as trying to build customer relation system feature #125125. There is literally one user input to the system, that is the throttle position. If the system even appears to work correctly in all states, ship it. As an engineering effort an ECU is quite the accomplishment, as a software development effort its quite boring. Something like an infotainment system that can have lots of different states presents much more information to the user. It's actually a much more challenging to develop, because you'll have people instantly noticing when you've drawn the UI widget for feature #125125 wrong.

4 points by di 11y ago

a3n 11y ago

N. Don't write any code that isn't specified by a requirement. In a shop as large as VW, there are requirements. Investigations are only beginning, but at this point it's plausible that some of the coders involved didn't quite know what the purpose of their code was. VW execs jumped early to try to hang this on "one or two software engineers." Promote this publicly in the interests of "traceability," which everyone agrees is a good thing. Want it privately in the interests of self-preservation. If a company wants something built, particularly in a regulated industry, they damn well better declare it. Which reminds me, it will be interesting to see how the VW code in question relates to their requirements systems.

hydrogen18 11y ago
Why do think VW would bother issuing formal requirements?
- a3n 11y ago
  Because it's inconceivable that they could manage software and hardware production without them. They're huge. You can't ad-hoc something that large. Or are you asking why would VW bother with requirements for the cheating subset? Well, that would be my point then. Don't write software against something a manager mentioned in a meeting or in your cube.
  - hydrogen18 11y ago
    If we're talking strictly about an ECU, I'd guess that most of them are a codebase that is a complete disaster. The only management activity around ECU development is likely something to the extent of "6 engineers at 1.12 times our standard engineer cost for 6 months will cost us...". My guess is all of them just do shit until it works. There are tons of sensors, valves, etc. that need to be managed but it isn't anywhere near as complex as trying to build customer relation system feature #125125. There is literally one user input to the system, that is the throttle position. If the system even appears to work correctly in all states, ship it. As an engineering effort an ECU is quite the accomplishment, as a software development effort its quite boring. Something like an infotainment system that can have lots of different states presents much more information to the user. It's actually a much more challenging to develop, because you'll have people instantly noticing when you've drawn the UI widget for feature #125125 wrong.