IT Litigators Library

The IT
Litigator’s
Library
Edward Yourdon
Ed Yourdon
email: ed@yourdon.com
Website: www.yourdon.com
Blog: www.yourdonreport.com
Twitter, LinkedIn, Facebook, Plaxo, Flickr: “yourdon”

Publication Details and Disclaimer

Published under the GNU Free Documentation License (GFDL) 2

Publication Details and Disclaimer
This presentation is an open-content collaborative document. Anyone with an Internet connection and World
Wide Web browser may view and/or alter its content — for better or worse. Please be advised that nothing in
this document has necessarily been reviewed by Ed Yourdon ("Ed"); the theories and business practices expressed
by the document are not necessarily his.

This isn't to say you won't find valuable and accurate information herein; however, Ed cannot summarily
guarantee the validity of this document. The content of any given page may recently have been changed,
dumbed-down, or other wise edited by someone whose opinion does not correspond to Ed’s original material (or
any subsequent drafts).

Neither Ed, nor any of the contributors, collaborators, nor anyone else connected with this document, can in any
way whatsoever be held responsible for the appearance of any inaccurate information, or for your use of the
information contained in or linked from this document.

You are being granted a limited license to copy anything from this document; it does not create or imply any
contractual or extra-contractual liability on the part of Ed, nor any of the contributors, collaborators, or
viewers of this material.

There is no agreement or understanding bet ween you and Ed regarding your use or modification of this
information beyond the GNU Free Documentation License (GFDL); neither is Ed responsible should someone change,
edit, modify, or remove any information that you may post on this document.

Any of the trademarks, ser vice marks, collective marks, design rights, personality rights, or similar rights that
are mentioned, used, or cited in this document are the property of their respective owners. Their use here does
not imply that you may use them for any purpose other than for the same or similar informational use — as
recognized under the GFDL licensing scheme. Unless other wise stated, Ed and this document are neither endorsed
by nor affiliated with any of the holders of any such rights; as such, Ed cannot grant any rights to use any
other wise protected materials. Your use of any such or similar incorporated property is at your own risk.


Introduction


Introduction
✮ Large percentage of IT projects are over budget, behind
schedule, buggy, unusable, inflexible, etc.


Introduction
✮ Hence many disappointments, cancelled projects,
system failures, financial losses, injuries, regulatory
penalties, loss of competitive advantage, etc.


Introduction
✮ Some of which leads to litigation…


Introduction
✮ It would be helpful for attorneys to have a better
understanding of why IT projects fail:


Introduction
✔ The nature of IT risks


Introduction
✔ Peopleware issues


Introduction
✔ Process and methodology issues


Introduction
✔ Technology issues


Introduction
✔ Technology issues
✮ To help accomplish this, a recommended reading list is
provided. The book titles are all hyperlinks that will
lead you to the appropriate page on the Amazon web
site.

The Nature of IT Risks, #1
✮ Brooks, Fred. The Mythical Man-Month (20th anniversary edition,
Addison-Wesley, 1995)
✔ One of the earliest, and most famous, “bibles” about basic software engineering principles and
what can go wrong on large, complex projects. Originally published in 1975, and then updated
in 1975
✮ DeMarco, Tom. The Deadline: A Novel About Project Management
(Dorset House, 1997)
✔ Another summary of the many issues and risks associated with large complex — and highly
political! — projects, written in the form of a novel. Appears to be light reading, but covers
many deep, significant points.
✮ Dorner, Dietrich. The Logic of Failure: Recognizing and Avoiding
Failure in Complex Systems (Addison-Wesley, 1996)
✔ To many veterans, managing a large, complex project is not about achieving success, but
rather avoiding failure — or at least anticipating failure early enough to be able to avoid it,
minimize it, and/or cope with it.

✮ Jones, Capers. Assessment and Control of Software Risks (Prentice
Hall, 1994)
✔ Jones approaches the subject of IT risks in the manner that health officials catalog
and describe diseases and contagions: symptoms, carriers, consequences, cures,
etc. A very different, and quite intriguing, perspective on software risks.


The Nature of IT Risks
✮ Jones, Capers. Patterns of Software Systems Failure and Success
(International Thomson Computer Press, 1996).
✔ More of a statistical summary of the various causes (individually, and in tandem with one
another) of software failures
✮ Hall, Elaine. Managing Risk: Methods for Software Systems
Development (Addison-Wesley, 1998)
✔ Risk management is not just about identifying risks, but also developing processes and
strategies for escalating them (on the assumption that the project manager often lacks
authority to deal with them personally), managing, and mitigating them
✮ Minasi, Mark. The Software Conspiracy (McGraw-Hill, 1999)
✔ Argues that many of the larger software-product vendors (especially the “shrink-wrap”
companies) know exactly how mediocre their products are, but are more concerned about
getting their (buggy) products into the marketplace quickly than assuring that their customers
will receive well-tested, usable products

✮ Neumann, Peter. Computer-Related Risks (Addison-Wesley, 1995)
✔ Drawn from thousands of examples, and a couple of decades of coverage of computer-related
problems and failures reported in the Communications of the ACM. Catalogs many different
categories of failures, and reminds the reader of things like the law of unintended
consequences, and other subtle causes of problems.


Peopleware #1
✮ Austin, Robert D. Measuring and Managing Performance in
Organizations (Dorset House, 1996)
✔ Vendor marketing brochures, and documents associated with litigation, often claim that IT
project personnel are either talented, competent, or incompetent. But how do you measure the
performance and skills of IT people? Austin, a professor at the Harvard Business School, has
some provocative things to say on the subject.
✮ Curtis, Bill et al. People Capability Maturity Model (Addison-Wesley,
2001)
✔ The people who brought us the SEI-CMM have now got a model that describes the “maturity”
of IT organizations, in terms of their human-resource practices — e.g., the sophistication and
maturity of recruiting, hiring, motivation, training, compensation, and other practices.
✮ DeMarco, Tom, and Timothy Lister. Peopleware: Productive Projects
and Teams (2nd edition, Dorset House, 1997)
✔ Considered by many to be the bible in terms of “best practices” for nurturing the individuals
and teams who build IT systems. DeMarco and Lister once worked in my software consulting/
training company, and Peopleware is sometimes known as “a compendium of all the things Ed
did wrong when managing his company.”
✮ Humphrey, Watts. Managing Technical People: Innovation,
Teamwork, and the Software Process (Addison-Wesley, 1997)
✔ A more traditional, and classical, treatment of issues, strategies, and guidelines for managing
technical people — from the “father” of the SEI-CMM at the Software Engineering Institute.


Peopleware #2
✮ McCarthy, Jim. Dynamics of Software Development (Microsoft Press,
1995).
✔ From the former manager of Microsoft’s Visual C++ project team, a highly readable, no-
nonsense discussion of both peopleware issues and other project management issues. Great
aphorisms and suggestions like “Don’t flip the bozo bit” and “Never let a programmer
disappear into a dark room.”
✮ Weinberg, Jerry. The Psychology of Computer Programming (silver
anniversary edition, Dorset House, 1996)
✔ First published in 1971, and generally considered the first book acknowledging that software is
written by people, and that the human/sociological/psychological issues need to be kept in
mind, because software is not written by robots. Updated 25 years after its original publication,
and still highly relevant. Technology has obviously changed enormously in the past 25 years,
but (with rare exceptions) people are still people.
✮ Whitaker, Ken. Managing Software Maniacs (John Wiley & Sons,
1994)
✔ As the title implies, this book is about the difficult job that project managers usually have,
when managing high-strung programmers working on a high-pressure project — a task
sometimes described as “herding cats”. And if you believe Whitaker’s message, and follow his
guidelines, then arguably there is no excuse for letting even the wildest, craziest project get
out of control because the programmers are “unmanageable”.


Process #1
✮ Beck, Kent. eXtreme Programming eXplained: Embrace Change
(Addison-Wesley, 2000)
✔ For many small, internal, non-safety-critical IT projects, a methodology known as “extreme
programming” has become quite popular. There are about half a dozen books discussing
different aspects of it; this one, by Kent Beck, is the first and arguably the best.
✮ Boehm, Barry. Software Cost Estimation with COCOMO II
(paperback edition, Prentice Hall, 2009)
✔ One of the “processes” that typically takes place at the beginning of a project (assuming that
schedule, budget, and other project parameters were not simply imposed by fiat) is
“estimating”. There are several mathematical models for doing this, of which COCOMO (an
acronym for COnstructive COst MOdel is probably the best known. The author, Barry
Boehm, is considered one of the pioneers and gurus in the field.
✮ Davis, Alan. 201 Principles of Software Development (McGraw-Hill,
1995)
✔ Alan Davis is a world authority on software requirements management, and has written
several books on the subject. But this book is pretty much what the title implies: a bunch of
short (one-page or less), simple, bite-sized principles about software development.
✮ Highsmith, James. Adaptive Software Development (Dorset House,
1999)
✔ In many of today’s IT projects, the classical task of defining requirements is considered
fruitless, because (a) the users don’t know what they want, (b) they change their mind, and
(c) the external world imposes its own chaotic changes throughout the course of the project.
Thus, success is often not based on having a rigid, disciplined — but static and
unchangeable — process, but rather by having a process that emphasizes agility and
flexibility. Highsmith is one of the most articulate advocates of this new IT approach.

Process #2
✮ Leffingwell, Dean and Don Widrig. Managing Software Requirements:
A Unified Approach (Addison-Wesley, 1999)
✔ Leffingwell and Widrig point out that there are three separate issues associated with software
requirements: (a) eliciting the requirements from users who often don’t know what they want,
(b) documenting the requirements so that concurrence and communication are possible, and
( c) managing the requirements throughout the course of the project, when new requirements
are added and old requirements are dropped, and the relative priority of remaining
requirements goes up and down dynamically
✮ McConnell, Steve. Rapid Development: Taming Wild Software
Schedules (Microsoft Press, 1996).
✔ The title speaks for itself. Much of the emphasis in this book, by the former editor of IEEE
Software, and a recognized guru in the field, has to do with prototyping, iterative/spiral
development methods, risk management, etc.
✮ Metzger, Philip and John Boddie. Managing a Programming Project
(3rd edition, Prentice Hall, 1995)
✔ A more traditional project management book, which covers the “basics” of managing and
controlling progress (or lack of same), schedules, budgets, estimates, etc etc.

✮ Paulk, Mark C., Charles V. Weber, Bill Curtis, Mary Beth Chrissis, and
a cast of thousands. The Capability Maturity Model: Guidelines for
Improving the Software Process (Addison-Wesley,1995)
✔ A full and complete treatment of the basic SEI-CMM, by the key people who worked on it at
the Software Engineering Institute. This may eventually be superseded by SEI-CMM/I

Process #3
✮ Robertson, Suzanne, and James Robertson. Mastering the
Requirements Process (Dorset House, 1999).
✔ A second excellent book on software requirements; a third such book is the one written by
Karl Wiegers. The Robs (as they were known when they worked for my company) introduce
a simple approach called VOLARE for managing requirements
✮ Sullivan, Ed, and John Robbins. Under Pressure and On Time
(Microsoft Press, 2001).
✔ A Microsoft perspective on managing projects that are under intense time pressure, but
which still have to be finished on time.
✮ Yourdon, Edward. Death March (2nd edition, Prentice Hall, 2004)
✔ A death-march project, loosely speaking, is one that for which a COCOMO-generated
schedule, budget, and project team has basically been cut in half; in most cases, it appears
that the only way to succeed is for the team to work a “death-march” schedule of heavy
overtime. For IT litigators, a key question is whether the death-march nature was (or should
have been) recognized from the very beginning, or whether a properly-planned project has
somehow degenerated into a death-march. Also, a key question is which of the “regular”
process activities can be compromised, shortened, or ignored in a death-march.

✮ Yourdon, Edward. Managing High Intensity Internet Projects
(Prentice-Hall, 2001)
✔ An updated version of the death-march project, dealing specifically with the super-intense
dot-com, e-business, and Internet-oriented projects developed almost everywhere in the late
1990s and early 2000s.

Technology
✮ Dertouzos, Michael. What Will Be: how the new world of
information will change our lives (HarperEdge, 1997)
✔ A futuristic look at computer technology by the late Director of MIT’s computer lab.
✮ Landauer, Thomas K. The Trouble With Computers: Usefulness,
Usability, and Productivity (MIT Press, 1995).
✔ A highly skeptical assessment of the powers and possibilities of computer technology,
especially useful to help offset the gushing optimism of books like Negroponte’s below.
✮ Negroponte, Nicholas. Being Digital (Alfred A. Knopf, 1995)
✔ Written by the former director of MIT’s Media Lab, at the beginning of the hype-period
associated with the Web. Negroponte was also one of the founding columnists of Wired
magazine
✮ Postman, Neil. Technopoly: The Surrender of Culture to
Technology (Random House, 1993)
✔ Written by a British sociologist and management consultant, who has a very dour opinion
of the impact of technology on much of what is considered “good” about our current
organizational and social culture. Depressing, but recommended reading.
✮ Stoll, Clifford. Silicon Snake Oil: Second Thoughts on the
Information Highway (Doubleday, 1995)
✔ Somewhat dated at this point, but still worth reading — by the author of The Cuckoo’s
Egg, which described one of the first high-tech computer hacking cases. Stoll is a wild,
crazy, but brilliant and captivating speaker; if you ever hear that he’s on the program of
any conference you’re attending, be sure to wear a Kevlar vest, but don’t miss his talk!


Conclusion


Conclusion
✮ IT failures are often blamed on technology issues, but
that’s only a small part of the story


Conclusion
✮ Key issue is whether potential risks were acknowledged
and managed properly throughout the project.


Conclusion
✮ Example: look at the Appendix to the Rogers Commission
Report on the Space Shuttle Challenger Accident, in
which Nobel-prize winner Richard Feynman observed:


Conclusion
✔ “It appears that there are enormous differences of opinion as to the probability
of a failure with loss of vehicle and of human life. The estimates range from
roughly 1 in 100 to 1 in 100,000. The higher figures come from the working
engineers, and the very low figures from management. What are the causes
and consequences of this lack of agreement? Since 1 part in 100,000 would
imply that one could put a Shuttle up each day for 300 years expecting to lose
only one, we could properly ask ‘What is the cause of management's fantastic
faith in the machinery?’”


Conclusion
✔ “It appears that there are enormous differences of opinion as to the probability
of a failure with loss of vehicle and of human life. The estimates range from
roughly 1 in 100 to 1 in 100,000. The higher figures come from the working
engineers, and the very low figures from management. What are the causes
and consequences of this lack of agreement? Since 1 part in 100,000 would
imply that one could put a Shuttle up each day for 300 years expecting to lose
only one, we could properly ask ‘What is the cause of management's fantastic
faith in the machinery?’”
✮ Bottom line: the more you understand about why IT
failures occur, the better you’ll be able to prosecute and/
or defend such cases.


IT Litigators Library

More Related Content

Similar to IT Litigators Library (20)

IT Litigators Library