by Evan Robinson
Life changes. When I finished my last review, I was working at Electronic Arts and the height of consumer game technology was the PC, the Jaguar, and the 3DO, with Genesis (and Sega-CD) and SNES hanging in there. Now I've been independent again for a year and we have Sega Saturn and 32X and Sony PlayStation on the shelves. Sega and Matsushita (Panasonic — first manufacturer of 3DO hardware) are writing PC software (Sony has been for some time). Ultra 64 and 3DO M2 are still waiting to help confuse the 32+ bit consumer market. In a world bombarded by change, we seem to get more than most. Everyone I know is predicting confusion in the marketplace in the foreseeable future.
Some things don't change, though. Products get bigger and more expensive to build, and the pressure to get them out on time, on budget, and without bugs continues (and increases). More and more money is spent on content (which will be useless without code to make it work).
I am trying to bring to your attention books that will help you get your products done in a timely and efficient manner, and at the same time help you get better at what you do. Occasionally I may try to steer you away from something I think is a major stinker. If I keep doing these reviews I'll generally try to give you one full length and one "quickie", as I have this time. Your comments and recommendations are welcome. Feel free to email me.
Assessment and Control of Software Risks
Yourdon Press Computing Series, 619 pages, $35.
Every development organization has problems, and Assessment and Control of Software Risks (ACSR) is designed to help you recognize and cure or prevent them. Modeled after Communicable Diseases in Man (a series of ground-breaking books published by the US Public Health Service), ACSR lists 60 of the most common and most serious risks associated with creating software. Each risk description includes a Definition, categories of Severity (including a current US average value), Frequency, Occurrence, Root causes, Cost impact, Methods of prevention and control, Support (Product, Consulting, Education, Publication, Periodical, and Standards) and more.
The basis of ACSR is that problems in software development can be diagnosed and treated in much the same way that diseases can be diagnosed and treated. And just as good doctors do not diagnose and treat themselves, good software engineers (and their organizations) will not rely wholly upon self-examination but will bring in outside experts to assess their current state. There are professionals who perform Software Assessments on development organizations (Jones happens to be one — as such he may be selling something). If I had the opportunity to do so, I would have an assessment done of my organization to find out just where we are. My suspicion is that there are few companies in the games business above Level 2 on the SEI scale. And I've upgraded that estimate significantly in the last year or two. (For those of you unfamiliar with the Software Engineering Institute scale, it is a measure of maturity in development organizations. The five levels are Initial (unpredictable and poorly controlled), Repeatable (can do follow-on projects without making the same mistakes), Defined (uses a well-defined and effective methodology), Managed (methods are not only effective but are measured), and Optimizing (leading-edge, with full reusability, modern methods, etc.). The SEI scale is not the only way of measuring an organization's ability to develop software — the Software Productivity Research (SPR) also does assessment and has a different output scale.)
It's entertaining (and sobering) to look up a risk and see how it applies to your organization, then compare your organization to the US average value. For example, the average US software project suffers from Excessive Schedule Pressure such that it causes "low quality, low morale, excessive overtime, and schedule delays". Root causes come from two basic areas: initial schedule determination and large software projects. A side note is that some managers and staff members like working under pressure because it makes the work seem important. Projects where "schedules are set before requirements are defined are highly susceptible". The indirect costs of Excessive Schedule Pressure include low quality and higher than normal defect repair costs (up to 4 times higher). The prognosis is not favorable (at least until after the end of the century). Even when the technical problems are solved, marketing pressure must be addressed.
Gee, it doesn't sound like any software company I've ever been associated with! <sheepish grin>
From Ambiguous Improvement Targets to Slow Technology Transfer, problems common to software engineering organizations all over the world are covered. Those I've seen personally in our industry include Corporate Politics; Cost Overruns; Creeping User Requirements; Crowded Office Conditions; Error-Prone Modules; Excessive Schedule Pressure; Excessive Time to Market; Inaccurate Cost Estimating; Inadequate Compensation Plans; Inadequate Curricula (Software Engineering and Software Management); Inadequate Measurement; Inadequate Software Policies and Standards; Inadequate Project Risk Analysis; Inadequate Tools and Methods (Project Management, Quality Assurance and Technical Documentation); Lack of Reusable Architecture, Code, Data, Designs, Documentation, Project Plans, Test Plans, Test Cases, and Test Data; Low Productivity; Low Quality; Low Status of Software Personnel and Management; Low User Satisfaction; Missed Schedules; Poor Organization Structures; and Silver Bullet Syndrome.
With all those problems how do we succeed so often? Conditioning and Guts, as Ed Parker said. We do things the hard way much too often. Our users accept buggy software because they're used to it and they don't believe it'll get better. The first step toward improvement, they say, is admitting we have a problem. Merely scanning this book will convince you that we have a problem (many problems, in fact). Carefully reading it will give you the idea that all our problems are solvable with the procedures contained herein. Don't believe that. That's Silver Bullet Syndrome. Jones points out that excessive belief in any particular technique constitutes a problem. One way to avoid Silver Bullet Syndrome is to look at a series of small improvements, not one large fix to everything that's wrong.
I find ACSR's medical analogy useful partly because we rarely blame people for being ill (there are of course exceptions). In particular we rarely blame ourselves for becoming ill. If we can find a way to avoid blaming ourselves for the poor state of our engineering, we may find it easier to improve ourselves. ACSR may start you on a road to significant improvement in your development organization. I recommend it for anyone who oversees a development organization, especially those managing multiple development teams.
Procedural Elements for Computer Graphics
David F. Rogers
McGraw-Hill Book Company, 433 pages, $28.95
There appears to be a never-ending supply of books on computer graphics. Not only do we have series like Graphic Gems, the venerable Adams books and the more current Stevens volumes, old stalwarts like Foley and van Dam (Fundamentals of Interactive Computer Graphics) crop up again in new expanded editions. I seriously doubt I shall ever find a single work on graphics which covers the basics so well I don't want another on the same topic. Over time I seem to see (and collect) enough graphics books to fill at least one entire bookcase in my office (too small already).
Procedural Elements for Computer Graphics does not suggest it is the only volume you need. Given its age (published in 1985) it could hardly be the be-all and end-all of graphics algorithms. But it is a fine addition to your shelf nonetheless. For one thing, it is a reference volume, and as such, it never leaves the full algorithm as an exercise for the reader. For another, it politely provides many important algorithms in code (pseudo-code, but sufficiently C-like to be easily readable) instead of easily misunderstood (or poorly worded) English. Finally, while I have not tried all the code in the book, the code I have tried works, so I have confidence in the rest.
If you want to know how to draw a line or circle, fill a polygon, antialias, clip in two or three dimensions (lines, convex or concave polygons, or volumes), do hidden line or surface removal, or use a simple shading model (Gouraud or Phong), you'll find it here in an easily understood form. It is almost always the first place I look when I want an overview of anything it covers.
If you're looking for the only graphics book you'll ever need, this isn't it. If you're looking for a good introductory volume that holds your hand through derivations, this isn't it. If you care more about getting it right the first time than using the latest whiz-bang technology, or you want something to refresh your memory about the graphics course you took in college N years ago, I believe you want this book. But you can't have my copy.
Copyright © Evan Robinson. All Rights Reserved.