In April, at the New York City SPIN (Software Process Improvement Network link) meeting, Ed Yourdon gave an informative and generally sobering presentation on software litigation. Yourdon, a long time systems designer and proponent of software discipline and engineering practices and processes, has, in the past 10 years, found himself increasingly involved in software litigation. Sometimes he's an expert witness; sometimes he's consulting with one side or another. Ed said one thing that's clear is that litigation is increasing. He also said that the number of lawyers with engineering and computer science education and background is also increasing. These lawyers know what it takes to build, deploy, and maintain computer-based systems.
Ed focused on his experiences involving failed projects. One key learning arose from his work with lawyers in the run up to Y2K. When asked about how to mitigate the risks of project failures, the lawyer's first suggestion was, don't let projects fail. Hey, there's a good idea! When asked how to accomplish that, the lawyers suggested having processes that mitigate the risks of failure. Another good idea! And a sure way to have a process, they said, is to write down what you intend to do and then do it. Holy Batman, Robin, is that it? As Ed said many times during the evening -- it's straightforward project management. Be rational, exercise common sense, and use protection.
Ed's talk is available here
(PDF), and it's richly linked to ancillary and
reference material. The key points that stayed
with me from this talk are (1) do write
contracts; (2) get lawyers involved early ...
really!; (3) use some common sense.
[Update: proof-reading ... you can't get away
from it.]
A couple of asides. First, Ed mentioned that he's stopped using Powerpoint in favor of a mind-map program. And while his PDF presentation starts simple and grows in complexity as he speaks, it prints on a single page. I'm seeing more non-Powerpoint presentations these days and it's mostly a good thing. There are just so many bullet points that I can look at before I'm ready to just take a bullet ... or use one.
Second, what struck me about this meeting was the dearth of attendees under, say, 40 years of age. I wondered where all the younger programmers, software engineers, and project managers are meeting to talk about their work and to keep in touch with new trends. I don't believe it's all on blogs. People do still meet. But where?