December 2000
Volume 3 • Number 1

Contents

Resource Reviews

DEVELOPMENT METHODS

Adaptive Systems Development

James A. Highsmith III. 2000. New York: Dorset House Publishing Co. 358 pages. (CSQE Body of Knowledge areas: Software Processes, Software Project Management)

Reviewed by Pieter Botman

It was surprising and pleasing, upon scanning the list of references in this book, to come across several references to Peter Senge’s benchmark work, The Fifth Discipline. James Highsmith does more than pay lip service to Senge’s ideas. He makes a point of restating Senge’s principles–the disciplines operating in a “learning organization.” Ironic as it may seem, in the software field it is rare that any reference is made to these principles, since they are somewhat high level, abstract, and management oriented. Highsmith describes the adaptive software organization, and his guidelines and frameworks are consistent with Senge’s principles. This consistency is appealing and thought-provoking, since software organizations might be one of the purest manifestations of learning organizations.

This book is aimed at project teams faced with “high speed” and “high change” environments. In the first portion of the book, the author devotes a fair amount of space to setting the table–explaining the motivation for a more dynamic approach to software development. Not many readers will disagree with the author in his criticism of overly prescriptive, overly bureaucratic, and inflexible software development processes (dubbed “monumental” software development).

The second portion of the book describes an adaptive approach or management model, where the thrust is to break down bureaucratic barriers, to reduce “process,” and to facilitate collaboration and learning. This discussion is sweeping and covers practices at both the project and organizational levels. One major thrust of the author is the focus on results, and the rigorous management of components, not process artifacts. He also addresses concerns about scaling up rapid and flexible development environments:

“...as project size increases...defining and monitoring component dependencies becomes a critical management issue.... Project Managers should carefully identify dependencies, establish adequate monitoring processes, and improve their problem-anticipation skills.”

The author’s vision for an adaptive organization in this book is driven not only by the need for rapid development, but also for reducing large-scale waste of time and energy. He has the early stages of development clearly in his sights, as he attacks overly formal requirements documents, excessive detailed project planning, and prescriptive methodologies (which focus on the “how” and not the “what”).

Highsmith discusses quality in an almost philosophical manner. He notes that quality does not consist solely of measured characteristics (such as defects), but is in fact someone’s perception of value, driven by his or her own weighted set of attributes (such as functions/ features, performance, schedule, defects, and resources). He argues against a fixation on zero defect software, explaining that the “good enough” approach:

“...does not mean settling for average, but advocates delivering the best mix of attributes in a given competitive situation.”

This book’s major contribution is a thoughtful examination of the environment required for flexible adaptive development teams and organizations. Readers should not expect a detailed low-level cookbook approach to rapid software implementation, as this book devotes most of its space to higher-level issues, those relating to management practices, the environment, and larger-scale cultural issues. Understandably specific technical practices (such as those relating to architecture, design, and testing) are not addressed here.

Rapid prototyping, rapid application development, spiral development, and incremental and iterative development have all been introduced and popularized in recent years. The rational unified process and extreme programming are now becoming well known. It would be foolhardy to compare adaptive systems development directly to these other methodologies, frameworks, techniques, and guidelines. Senior software people must be able to evaluate the relative strengths and weaknesses of various approaches, and select what is appropriate for their respective environments and project/product constraints. They will benefit most from this book.

Taking another cue from Peter Senge, one would hope Highsmith continues with the development of his vision, publishing more specific (if condensed) case studies like The Fifth Discipline Fieldbook. It would be fascinating to be able to study organizations instituting various changes and applying these principles in difficult situations in order to become more flexible, adaptable, and ultimately, more successful.

Pieter Botman is a professional engineer registered in the province of British Columbia. With over 20 years of software engineering experience, he is currently an independent consultant, assisting companies in the areas of software process assessment/ improvement, project management, quality management, and product management. He can be reached at p.botman@ieee.org.

SOFTWARE PROCESSES

Programming Interviews Exposed

John Mongan and Noah Suojanen. 2000. New York: John Wiley & Sons. 272 pages. (CSQE Body of Knowledge areas: General Knowledge, Conduct, and Ethics; Software Processes)

Reviewed by Milt Boyd

Many years ago, it was popular for interviewers to say, “I’d like to see how you think,” and they would present a puzzler in math or logic: “A farmer had two buckets...” or “Alice and Barbara were sisters...” or “Two trains approach...” or “Students at the school march in formation....”

There were three ways through these: Repeat the answer from another interviewer or interviewee, experience an “Aha!” moment, or slog through the details. It is not obvious how this was related to real engineering work, and mercifully, it went out of fashion in a few years.

It was surprising to find a book whose premise is that interviewers use exercises in code to judge candidates. Some interns and recent hires confirmed this to be true. What is the connection between working out a 15 or 20 minute problem, and working on a real project?

The authors provide answers to this and other topics. They give good advice for the job-hunting software engineer, basing this on what is, rather than what might be in some nearly perfect world.

The book is organized into 11 chapters, starting with “The Job Application Process.” After all, one does not get to face the problems until he or she gets the interview. The second chapter is “Approaches to Programming Problems.” It emphasizes the process, solving the problem, and analyzing the solution, with help when one gets stuck. Both in work and in interviews, one can get points by recognizing that he or she is stuck and that an approach is not working.

The next seven chapters are organized by problem type: linked lists; trees and graphs; arrays and strings; recursion; counting, measuring, and ordering; graphical and spatial; and other programming topics. If readers “know the answer” the discussion is reasonable; if they do not, then it is straightforward and helpful in getting to an answer they can understand. The range of problems is plausible, given the constraint that each has to be stated, solved, and discussed in the relatively short time of an interview.

The solutions to the problems are almost always analyzed with respect to space and time. Improved solutions that require less space or time often replace initial solutions. Occasionally, solutions are analyzed for the ability to be generalized or applied to other problems related to the presenting problem. They are rarely considered from the point of view of testability, or robustness of operation, which may be very important in real projects.

The next chapter concerns knowledge of specific topics. The interviewer wants to judge one’s breadth or depth of competence, often starting from topics mentioned in one’s resume. As before, the questions are representative, not exhaustive. They usually involve contrasts between two ways of doing things.

The last chapter is a collection of nontechnical questions: “What do you want to do?” “Why should we hire you?” “Do you have questions?” are all covered, with the usual others. For some candidates, these will probably be more troublesome than the code, and the discussion will usually be helpful.

For those with a couple years toward a computer science degree, some knowledge of C++ (and possibly Java), and seeking work experience in general development, this book is a good preparation for interviews. For those with more experience, it is a fine collection of clever puzzles in the software profession, giving a basis for fun and discussion with one’s colleagues. This book is highly recommended.

Milt Boyd is a member of ASQ’s Software, Reliability, and Quality Management Divisions. He is certified as an ASQ Quality Manager and is on the IRCA registry of Certificated Quality Management System Lead Auditors. He is currently employed as a system engineer by Avidyne Co. of Massachusetts.