Executive Vice President

David M. Cummings is the Executive Vice President of the Kelly Technology Group in Santa Barbara, CA. He has over 35 years of experience in the design and implementation of software systems, many of which are embedded systems. Nine of those years were spent at the Jet Propulsion Laboratory, where he designed and implemented flight software for the Mars Pathfinder spacecraft. He holds a bachelor's degree from Harvard University, and a master's degree and a Ph.D. from UCLA. For more information, please see www.kellytechnologygroup.com.


's contributions
    • I am not saying that I don’t believe a car computer could malfunction. But the fact that a malfunction could occur is not the point. The point is that the plaintiffs didn’t show that it is more likely than not that a computer malfunction caused this particular accident. (“More likely than not” is the legal burden of proof required of the plaintiffs.) They claimed they had a theory to show this, but their theory falls apart under technical scrutiny. I understand that to you this may not be that relevant, but in a trial such as this it is highly relevant. The plaintiffs simply didn’t meet their burden of proof.

    • Thank you for your comment. Although coding standards serve a useful purpose (and I have used them on many projects), I agree that just because code adheres to a coding standard doesn’t mean the code is high quality. As you suggest, one cannot meaningfully assess software quality without understanding the code and its underlying design. The plaintiffs’ criticisms of Toyota’s software quality based on metrics, including criticisms from an expert who did not even see Toyota’s source code, are reminiscent of situations I’ve encountered on past development projects. Outsiders were sometimes brought in to those projects who had limited real-world product development experience, and who assessed the quality of the software simply by gathering metrics, without understanding the code. These assessments invariably struck the development teams as being of questionable validity and usefulness. Tools such as static analyzers can be very valuable to development teams, but they can also be misused when in the wrong hands.

    • You make an interesting point. In response, I’d like to first point out that only one of the two embedded systems experts based his testimony on direct examination of the code. The first expert to testify did not see any of Toyota’s source code, yet his entire testimony was directed toward criticizing its quality. This leaves the second expert’s testimony. That expert made his trial testimony and slides available to the public and invited us to “judge for ourselves.” So apparently he felt that his trial testimony and slides were sufficient for the public to draw our own conclusions about his causation theory. And as I show, based on that information, which he provided for us to use in “judging for ourselves,” his causation theory is not credible. Also, of course, the evidence presented in his trial testimony and slides is the exact same evidence he presented to the jury to justify his flawed causation theory.

    • These are important points. Thank you. Due to space limitations, I focused my IEEE article on the plaintiffs’ flawed causation theory. But I have also examined the plaintiffs’ testimony on Toyota’s software quality, and I have serious concerns there as well. Here let me say just a few words about one of your points, 11,000 global variables. I think it is highly questionable to draw conclusions about software quality by simply counting global variables, without looking at why the decision to use them was made, and how they are actually used. There are many reasons why an engineering team might decide to use global variables after performing a risk-benefit analysis. For example, maybe Toyota decided to implement variables as global in order to support engine control calibration, which is not uncommon in automotive systems. Maybe they chose to implement variables as global in order to conserve stack utilization, even though those variables are only accessed in one place (they are not accessed globally), so that the risks of shared access are minimized. Maybe they decided to implement variables as global in order to minimize CPU utilization, even though those variables are only accessed in one place. (These are just a few examples.) The non-technical jury was made to believe by two software experts that the issue is black and white, and that if there are more than a handful of globals -- more than “five, ten” out of Toyota’s one million lines of code according to the first expert’s testimony -- then the software is of poor quality, period. This is overly simplistic and, in my opinion, very misleading.

    • I agree that we are not likely to ever know with certainty what went wrong in this particular accident. With that said, a fundamental issue for many automotive product liability trials ends up being driver error versus vehicle malfunction. There are “black box” recorders on some automobiles that capture pre-crash data, which in principle should provide evidence indicating whether a crash was due to driver error versus vehicle malfunction, and if vehicle malfunction, additional data that might enable a successful post-mortem. However, according to the testimony at this trial, the Camry model involved in this accident did not have such a pre-crash recorder. Furthermore, even if there is a pre-crash data recorder, then as long as it relies on software, care must be taken to minimize the risk that a failure in the computer system can compromise the integrity of the pre-crash data that is recorded.