4 ms·

My new car has a radio with a touch-screen interface. When I turn the car on there's a space of about 10 seconds where the radio is operating but I can't change

by mark-r 9y ago

My new car has a radio with a touch-screen interface. When I turn the car on there's a space of about 10 seconds where the radio is operating but I can't change the station or volume or even turn it off. It's quite annoying when you were rocking out last time you were in the car and now you have passengers.

wpietri 9y ago
To me this is symptomatic of a long or broken feedback loop in the development process. E.g., a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. In that setting, nobody's going to say, "Hey, let's just pop this radio into our cars, live with it for a few weeks, and then figure out where we need to go next." It's too late. Instead I think the thing to do is force convergence early and often in the product timeline, so that the supposedly-little things like this have plenty of time to get noticed and fixed. A good example of this is Apple. I'm told that in consumer electronics the typical number of iterations with physical prototypes is 3-7. For the first iPod, Apple went through more than 100. The difference was enough for them to crush the competition so thoroughly that people these days are surprised to hear that there were MP3 players before the iPod (and smartphones before the iPhone).
- userbinator 9y ago
  a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. ...which is actually quite suitable for the safety-critical parts of a car like the ECU and other controllers that control the actual driving aspect, but not for everything else that doesn't need such a level of process. On the other hand, I suppose it could also be blamed on the lack of "performance is a feature" --- if they specified the radio to be as responsive as the accelerator and brake, for example.
  - wpietri 9y ago
    I think the choice of process is basically orthogonal. Waterfall and Agile processes done well both have been demonstrated to produce safety-critical software. (See, e.g., Nancy van Schooenderwoert's work in medical devices.) Both can produce dangerous software. (E.g., Toyota's "unintended acceleration" issues.) The question is much more about what practices you put in place to assure quality. I do think short-cycle methods have some intrinsic advantages, though. By making critical functionality available much earlier for testing, you get more time and more chances to make sure it's really safe. If early versions are bad, you get early warning signs that aren't available in a Waterfall process. And if testing turns up issues early on, it's much cheaper to make fundamental architectural changes: less code to change and more time to change it in. And Waterfall processes aren't at good at dealing with unknown unknowns; some things you only learn by trying them out.
FireBeyond 9y ago
Same, and it's all the more frustrating with the realization that what is effectively a tablet should be able to sleep for an inordinately long time, especially in "airplane mode" (mine has a SIM card, but there's no reason to be running an AP or Bluetooth when off), rather than cold booting, off a car battery.

by mark-r 9y ago

wpietri 9y ago

To me this is symptomatic of a long or broken feedback loop in the development process. E.g., a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. In that setting, nobody's going to say, "Hey, let's just pop this radio into our cars, live with it for a few weeks, and then figure out where we need to go next." It's too late. Instead I think the thing to do is force convergence early and often in the product timeline, so that the supposedly-little things like this have plenty of time to get noticed and fixed. A good example of this is Apple. I'm told that in consumer electronics the typical number of iterations with physical prototypes is 3-7. For the first iPod, Apple went through more than 100. The difference was enough for them to crush the competition so thoroughly that people these days are surprised to hear that there were MP3 players before the iPod (and smartphones before the iPhone).

userbinator 9y ago
a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. ...which is actually quite suitable for the safety-critical parts of a car like the ECU and other controllers that control the actual driving aspect, but not for everything else that doesn't need such a level of process. On the other hand, I suppose it could also be blamed on the lack of "performance is a feature" --- if they specified the radio to be as responsive as the accelerator and brake, for example.
- wpietri 9y ago
  I think the choice of process is basically orthogonal. Waterfall and Agile processes done well both have been demonstrated to produce safety-critical software. (See, e.g., Nancy van Schooenderwoert's work in medical devices.) Both can produce dangerous software. (E.g., Toyota's "unintended acceleration" issues.) The question is much more about what practices you put in place to assure quality. I do think short-cycle methods have some intrinsic advantages, though. By making critical functionality available much earlier for testing, you get more time and more chances to make sure it's really safe. If early versions are bad, you get early warning signs that aren't available in a Waterfall process. And if testing turns up issues early on, it's much cheaper to make fundamental architectural changes: less code to change and more time to change it in. And Waterfall processes aren't at good at dealing with unknown unknowns; some things you only learn by trying them out.

FireBeyond 9y ago

Same, and it's all the more frustrating with the realization that what is effectively a tablet should be able to sleep for an inordinately long time, especially in "airplane mode" (mine has a SIM card, but there's no reason to be running an AP or Bluetooth when off), rather than cold booting, off a car battery.