Slashdot Mirror

New submitter andyjl writes: The software industry lost one of its pioneers on Tuesday, January 20, 2016 when Ed Yourdon died from post-operative complications. Ed was a pioneer of Structured Programming methodologies, and was a prodigious author of software-related books, including topics such as "death march" projects, and the problems of Y2K. He was also a personal friend and fellow forensic software analyst specializing in the analysis of failed software development projects and the lack of software development disciplines. He once told me that he read a item on the Internet (which I cannot find) that said, "whenever a programmer writes a GOTO statement, somewhere a Yourdon dies." I am forced to conclude that one of you programmers out there did indeed write a GOTO statement on Tuesday and I want to know who it was. Look at what you did! Did you really have to use a GOTO? Adds reader theodp: Yourdon was a successful author, whose Slashdot-reviewed books included Rise and Resurrection of the American Programmer, Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects, Byte Wars: The Impact of September 11 on Information Technology, and Outsourcing: Competing in the Global Productivity Race. Yourdon's Time Bomb 2000!: What the Year 2000 Computer Crisis Means to You!, written with daughter Jennifer, was a Y2K best-seller.

Jason Bennett contributed this review of the depressingly named Death March : The Complete Software Developer's Guide to Surviving " Mission Impossible" Projects. But if you're ever part of a software project which seems to be going nowhere fast, and over very rocky roads, perhaps the words he's written will point you to a source of solace. This book seems to have some decent strategies for dealing with impossible demands and even more impossible deadlines. And while no book will give you a better boss or timetable, at least you'll know you're not the only one.

Death March author Edward Yourdon pages 218 publisher Prentice Hall rating 8 reviewer Jason Bennett ISBN 0-13-014659-5 summary Another excellent effort by Yourdon that gives insight into the "doomed to fail" project.

Background Ed Yourdon has a long and storied publishing history, most notably for his books on structured design and his duology (is that a two book series?) Decline and Fall of the American Programmer and The Rise and Resurrection of the American Programmer. Of course, he's better known recently for his (somewhat apocalyptic) Y2K books. This one, of course, is a couple of years old, but like most of the books I tend to gravitate to, addresses themes that endure. In this case, the desire to do more with less. The Scenario

Death March: [A project] whose "project parameters" exceed the norm by at least 50%. [The metaphor is used to suggest] a "forced march" imposed upon relatively innocent victims, the outcome of which is usually a high casualty rate. (2)

Yourdon's definition, as related above, does not necessarily imply a long-term project (although long-term death marches are worse than short-term ones), but instead describes a project with a low rate of success and a high personal impact. The project is either underfunded, underscheduled, understaffed, overfeatured, or some combination of the above. The introduction deals with the reasons DM projects happen, and why people actually agree to work on them. Having been on one myself, I can say that "ego" is one of the major reasons.

The subsequent chapters deal with various facets of the death march project, and how those facets are unique in such a project. Chapter 2, politics, has an especially interesting section on identifying what type of DM project one is on, and the chances of success for such a project. Yourdon rates projects on a four-quadrant scale: low and high likelihood of success, and low and high happiness factor (giving four combinations). Suffice to say, there are good combinations, bad combinations, and worse combinations. :-)

Chapter 3 deals with an important part of any project, but one that is hypercritical for any death march project: negotiation. Needless to say, good negotiation can turn a DM project into an almost-normal project, while bad negotiation can turn a bad situation into a nightmare. Yourdon provides some excellent tips on how to deal with upper management in these situations, which should be useful even if you've negotiated for a standard project before. Clearly, management is going to be much less forgiving in a DM situation.

Chapter 4 deals with "peopleware" issues in death march projects. As with negotiation, nothing really changes from a standard project to a DM project, but everything is emphasized. If you have poor workspace when you're on a normal deadline, consider how that workspace will affect you when you're under extreme time pressure. Overtime, and the limits of such, are another important issue Yourdon deals with.

Chapter 5 deals with an issue I've addressed many times in my reviews: process. I greatly appreciate Yourdon's take on process in a DM project. Simply put, while the Methodology Police will make any DM project worse, the lack of process will completely destroy one. Don't try to do all the paperwork while you're cramming to get the software out the door, but abandoning process will insure your failure. Things like requirements management and configuration management are all the more critical on a likely-to-fail project. If you lose only a week to a requirements change, that might be a quarter of your schedule!

Chapter 6, tools, simply reminds us that technology will not solve the human problem of programming. No CASE tool or supercompiler is going to come along to write your DM software for you. Use what you are most comfortable with, and you'll be the most productive.

The concluding chapter 7 proposes an interesting scenario: what if death march projects were to become normal? That is, how do you live and work rationally in an environment that is irrational? Suffice to say, this impacts everything about a software team, including the people who are hired and how careers advance within the company.

Throughout the book, Yourdon includes some excellent footnotes taken from correspondence with various software practitioners. These email excepts, gleaned from a questionnaire Yourdon sent out about the book's subject, give excellent insight into the nature of a death march project.

Although few people actually want to be sucked into a death march project, it will likely happen to most developers at some point in time or another. Being prepared for the occurrence might well mean your survival of such a project.

What's Bad/Good I found very little to dislike about this book. The text is concise yet thorough. The presentation is excellent. The ideas are reasonable and well-stated. I find Yourdon to be quite moderate in his position, neither justifying death marches nor railing against them overly. The advice on this book could easily be applied to any sort of project, and in fact is fairly standard in the literature, only ramped up for an intense, death march experience. Very little has changed in the industry since this book was initially published, and I doubt its timeliness will cease anytime soon. So What's In It For Me? If you write software, or work on any knowledge team, you will likely face a death march project at some point in your career. This book will help prepare you to deal with, and triumph over, such an experience. Table of Contents Preface

1. Introduction
2. Politics
3. Negotiations
4. People in Death March Projects
5. Processes
6. Tools and Technology
7. Death March as a Way of Life

Puchase this book from Fatbrain.com.

Jason Bennett has returned with a review of Mark Minasi's The Software Conspiracy. The book is basically a well-informed perspective of the state of the software industry - how it functions, what it does, and what's really going on. Click below to learn more.

The Software Conspiracy author Mark Minasi pages 271 publisher McGraw-Hill, 09/1999 rating 8/10 reviewer Jason Bennett ISBN 0071348069 summary A non-technical (but well-informed) telling of the state of the software industry

Background

A short digression before I start my review of this quite interesting book. I had the privilege of spending a few days in Seattle at a Construx Software training event on OOA/OOD using UML (hi, ImageX!). Amazingly enough, seven hours of flying each way will give one plenty of reading time, even including talking with those herding into the seats around you. Although I almost missed seeing my hometown Titans in the Super Bowl, I feel it was time well spent. Alas, I didn't get to see Steve, but maybe he'll email me if he reads this. :-)

Nevertheless, on to the business at hand. My book reviews have generally centered around the concept of software engineering, and how to apply its principles to development efforts. This week's book is more of a review of the state of the industry, and where the industry is trying to go. It should come as no surprise to most people reading this that the picture is not particularly pretty. There is, however, a glimmer of hope, but only if we can shake off the combined forces of greed and apathy. Hey, I never said it was going to be easy! <g>

What's the book about?

I believe the book's subtitle just about sums it up: "Why software companies put out faulty products, how they can hurt you, and what you can do about it." As I said in the summary, this book is geared toward non-technical software users in an attempt to explain to them why their software breaks, and why they shouldn't take it anymore. Many parts of this book will be well-known to regular Slashdot readers, but I dare say there are parts that will raise your hackles, regardless.

Chapter 1 is more or less an overview of the theme of the book: that software bugs are bad, that consumers and the media tolerate those bugs to an unreasonable extent, and that those same consumers must act to stem the trend toward more broken software. I'll address his on-point evidence as I discuss the following chapters.

Chapter 2 addresses an important, if not always obvious question: why do software bugs exist in the first place? The short answer is that it's difficult to think of every possible interaction and exception when devising an algorithm. The author employs some interesting mental experiments in the process of the discussion to make this fact more evident to non-programmers. He also mentions some historically important bugs (including the recently-historical Y2K). So far, nothing earth shattering....

With Chapter 3, the journey moves from easy to confrontational. To sum the chapter's theme in one sentence, software is buggy because programmers are slack and customers are more slack. As a counterpoint to the oft-heard statement, "Bug-free software is impossible," Minasi examines the Capability Maturity Model in detail, including how it has been shown to reduce error rates, and why most firms do not employ it. You won't feel complimented by this explanation. In short, most software firms don't try very hard to keep defects out of their software because they expect defects to occur, and (according to one survey), 15% of software firms do not even bother to test their software at all before shipping. I'm always one to quote the adage about the three kinds of lies, but somehow I'm inclined to believe this one. Why don't firms test? Basically because they can get away with it, and programmers don't want to be told they've made a mistake. The argument that bug-free software is too expensive is, of course, the same argument the meat packing industry made at the end of the 19th century, that wholesome meat was too expensive and impossible to produce. Fortunately for everyone, that excuse was eventually put to rest. Minasi believes the software excuse should be equally put out of its misery. The author does make one point that I disagree with, however, in that he claims that process isn't really for "geniuses," only "regular" programmers. I would argue, however, that everyone needs process to channel whatever genius they may possess, and that structure does not stand counter to creativity. The author also addresses some of the shortcomings of the CMM, but in the end believes that the evidence behind process, any process, is overwhelming.

Chapter 4 moves into another arena near and dear to our hearts: UCITA. As I read this chapter, I kept finding my jaw hanging open in astonishment at the gall of the software industry and the law they have crafted. This book is fairly recent, and thus the information current, although I recommend checking Cem Kaner's site or Slashdot for the most recent information. I won't go into bloody detail here, but suffice to say under UCITA the software industry can disclaim all responsibility for their software, while simultaneously putting unreasonable restrictions on your usage of that software. Amazingly convenient, huh? You could also no longer treat software like a book, as the software industry would completely control the software even after you had purchased/licensed it. Needless to say, a raw deal for the consumer.

Chapter 5 proposes an interesting rehash of Yourdon's The Decline and Fall of the American Programmer. Now, before I proceed, I've never actually read that book, so this analogy is based on my understanding of Yourdon's thesis. Basically, Minasi compares today's software industry to the auto industry of the 1950's. At that time, cars had more or less reached technological maturity. Marketing ruled the industry, as all the car were more or less the same. Planned obsolescence was invented, and quality declined as more and more useless features (e.g. fins) were added to cars. Of course, we all know the end of that story. The Japanese car industry invaded and smacked Detroit around for a while before the American automakers were able to recover. Minasi proposes that the America software industry is in a similar situation today, and UCITA could exacerbate that tendency. Could another country's software industry rise up? Minasi doesn't really offer any competitors at this point, but the threat is certainly there.

Chapter 6 exhorts users to stand up for quality software, just as they would stand up for quality in other products. Write letters. Don't pay for bug fixes. Help stop UCITA. Nothing earth-shattering again, but important nonetheless.

Chapter 7, the conclusion, paints two pictures of the future, one rosy, where buggy software is brought under control, and one bleak. I won't spoil them for you, but suffice to say the bleak one might surprise you. In any event, and effective storytelling mechanism.

Finally, there is an appendix of how to fix you current software, or at least get around its problems. Programmers might scoff at the information contained therein, but your mother will likely find it useful.

What's Good?

If you don't want too technical of a read, and you're interested in why software is in its current state, this is an excellent and informative book. The rationale is sound, and the information on UCITA is important to educate others about its dangers, especially when the time comes for a vote in your state. In short, read this book if you're tired of crappy software, or you don't know why software is crappy.

What's Bad?

On the other hand, if you think process is silly, and you're doing the best you can, dangit, you won't enjoy this book. I would like to think that most open source proponents would understand the importance of testing, but then again I don't remember reading too many test plans for OS projects. Whatever. Regardless, this book might not be for you if you want a detailed, technical discussion of the state of software, and you're already well up on your UCITA info. YMMV.

So What's In It For Me?

Regardless of who you are, coder or suit, what this book discusses will impact you. The U.S. software industry is going to be fundamentally shaped for decades to come by what happens in the next few months and years. It behooves you to understand the implications of where we are going, regardless of where you stand on the issue.

• Table of Contents
• Introduction
  1. When Some Bugs Bite, They Kill
  2. Why Are There Bugs? How Defects Happen
  3. It Doesn't Take a Genius, It Just Takes a Process: Building Good Software
  4. Software and the Law
  5. Bugs and the Country: Software Economics
  6. Fighting Back: How to Improve Software
  7. The Future
• Appendix: Software Self-defense
• Endnotes
• Index

SEGV, the old faithful of reviews, has sent in one of his latest reviews, this one of Edward Yourdon's latest book Rise and Resurrection of the American Programmer. For those of you who remember, several years ago, Yourdon wrote a book about how the American programmer/developer was doomed. Recent years have changed his opinion, and in this book he talks about the change that he says across the landscape. Fascinating idea-click below for the review. Rise and Resurrection of the American Programmer author Edward Yourdon pages publisher Prentice-Hall, Inc. rating 8.5 reviewer SEGV ISBN 0-13-121831-X summary A few years later, this industry autopsy remains an interesting and insightful read.

Decline and Fall

In the beginning of this decade, Edward Yourdon wrote Decline and Fall of the American Programmer, a pessimistic assessment of the American software industry in the global marketplace. I haven't read that book, but Ed conveniently summarizes it in the first chapter of this book.

His premise was simple: North American programmers are more expensive, less productive, and produce lower quality software than programmers elsewhere in the world. Therefore, he argued, competitive forces will drive them into extinction. He backed this up with a battery of data, figures, case studies, and anecdotal evidence.

This was apparently a wake-up call. After all, Ed wasn't merely an ignorant consultant. Rather, with 35 years in the industry, he had programmed mainframes and helped to invent structure design methodology. People listened to him.

Rise and Resurrection

But something happened during the first half of this decade. Not all of Ed's predictions came true; not all software development migrated to Bangalore, India; not all American programmers fell off the evolutionary ladder.

This book, Rise and Resurrection of the American Programmer, was written mid-decade to reexamine the situation then. Remember 1995? The web was just taking off, Microsoft Windows 95 was just released, Java was just beta, and Linux was just a hacker's toy.

Now the decade is closing, Ed is focusing on Y2K issues, and I've just finished reading this book. Some of Ed's views have dated, and some remain relevant. I'll try to enumerate a few of them here.

Java and the Internet

Ed stressed the importance of corporations embracing the internet. After all, he argued, competitors will. This has turned out to be correct. He also was extremely enthusiastic about Java, which wasn't even shipping when he wrote the book. Although most of the chapter explains the language and environment, and ends up sounding like a Sun white paper, one interesting nugget is Ed's suggestion that Microsoft may simply "embrace and assimilate" Java for themselves.

The Microsoft Paradigm

Let's be frank; Microsoft is quite successful, and does some things right. Ed dissects the corporation and comes to several conclusions. With section headings such as "The Dark Side of the Force" and "Into the Belly of the Beast," this chapter acknowledges public sentiment and should interest most Slashdot readers. But Ed concludes that Microsoft's hackers are growing up, and the corporation's powerful position will be difficult to assault.

Linux and Open Source Software

Ed pretty much missed this one. I didn't see any mention of Linux, hardly a blip on the radar when this book was written. Curiously, I also didn't see any mention of open source software, a wider concept that has been around for decades.

The closest hint I saw of the rising phenomenon was regarding Java's ability to change the economics of paying for software. Ed suggested that downloadable applets and web interaction make it possible to sell a "one-time usage" of software components, which could threaten existing software vendors with monolithic products.

An Enjoyable Read

At just over 300 pages, this book covers quite a few topics. I thought the chapters on peopleware and good-enough software were quite well done. Other chapters spurred me to learn more about the Capability Maturity Model and Personal Software Practices.

Ed is a frank and readable writer, and the book is quite digestible. It's fun to read recent predictions and analyze where they went wrong, and right (remember, hindsight's 20/20!). The book is almost a time capsule of the mid-nineties, which coincidentally being when I started working with computers in earnest was a refreshing read for myself. I think it will be for you as well.

Ed's web site is at www.yourdon.com.

Buy this book here.

TABLE OF CONTENTS

Preface
Trademark Acknowledgements
Part One: Decline & Fall Reexamined
1. The Original Premise
2. Peopleware
3. The Other Silver Bullets
Part Two: Repaving Cowpaths
4. System Dynamics
5. Personal Software Practices
6. Best Practices
7. Good-Enough Software
Part Three: The Brave New World
8. Service Systems
9. The Internet
10. Java and the New Programming Paradigm
11. The Microsoft Paradigm
12. Embedded Systems and Brave New Worlds
13. Past, Present, and Future
Appendix: An Updated Programmer's Bookshelf
Index