Facts and Fallacies of Software Engineering: A Review

This is the first of a series of articles on Scrum.
Facts and Fallacies of Software Engineering by Robert L. Glass should be read by anyone interested in Scrum and Agile methodologies and how they pertain to software development. Glass is not evangelizing Agile or Scrum with this book. Nevertheless, Glass illustrates many of the problems mitigated by Agile methodologies like Scrum. 

Facts and Fallacies of Software Engineering is broken into two parts: 55 facts and 10 fallacies. The facts are essentially uncomfortable facts of life. These facts are divided into chapters with these topics:
  • Management
  • Software Development Life Cycle
  • Quality
  • Research
 
Agile methodologies are based on an assumption that holds true in many cases: the requirements gathered at the start of a project will ultimately be incorrect. Glass is very blunt on the consequences of this problem. Fact 23 is: “One of the most common causes of runaway projects is unstable requirements.” Fact 24: “Requirements errors are the most expensive to fix when found during production but the cheapest to fix early in development.” Fact 25: “Missing requirements are the hardest requirements errors to correct.”

In Scrum, the focus is on completing a limited set of high-priority items in a short development cycle called a Sprint. This allows the customers to be honest about their top priorities without the concern that their other requirements will be ignored. Because the features are high priority, the customer can focus on presenting accurate requirements without getting bogged down thinking about lower priority issues. Facts and Fallacies of Software Engineering presents quite a few reasons to adopt such an approach without it being written as a pro-Scrum book.

Fact 28 reiterates the iterative processes used by Agile methodologies. Specifically: “Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal.”

Fact 29 demonstrates why Scrum’s use of small teams works well. “Programmers shift from design to coding when the problem is decomposed to a level of ‘primitives’ that the designer has mastered. If the coder is not the same person as the designer, the designer’s primitives are unlikely to match the coder’s primitives, and trouble will result.” The daily Scrum--the daily meetings that Scrum teams have--is an excellent time to flesh out any problems of this nature.

Scrum emphasizes testing as part of the Scrum cycle. Problems are most easily fixed when the developer has recently written the code. This approach to testing not only improves quality, it increases efficiency as well. This dovetails well with Glass’ Fact 31: “Error removal is the most time-consuming phase of the life cycle.”

Glass spends a lot of time demonstrating and discussing his observation that estimates are not decided by developers and are often arbitrary. “Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.”.

Glass convincingly advocates developer-generated estimates. Agile and Scrum take a different approach by simply not attempting to create accurate estimates. Instead, the approach of focusing on top priority items means that when the money runs out and the project ends, only low priority requirements are left unaddressed. The problem with convincing organizations of this approach is the discomfort of not having accurate estimates for budgeting. Glass convincingly points out that the developers’ estimates will be trumped by business needs anyway. Therefore, these estimates are a moot point anyway. I would further add that as functioning software needed by the business is being delivered rapidly and with high quality, budgeting for further features will only be easier.

Glass points out that developers and management have conflicting perspectives and goals. Fact 13: “There is a disconnect between management and their programmers. In one research study of a project that failed to meet its estimates and was seen by its management as a failure, the technical participants saw it as the most successful project they had ever worked on.” Should this organization have the goal that managers motivate developers, it seems that the managers are reaching this goal by accident, if at all.

Perhaps most important, Glass points out that “The chief enemy of product quality on most software projects is schedule pressure.” By focusing on top priority items, Scrum allows developers to add value without being distracted by complaints that deadlines that had little grounding in business needs and realities are not being met.

Glass give some recommendations that are not linked to any methodology (page 37). However, proponents of Agile methodologies will notice that these recommendations fit well within Agile. This is particularly true of his discussion of problems with requirements gathering and estimating. Because Glass is not advocating a specific methodology, Facts and Fallacies of Software Engineering can be used as an impartial source of information in environments where Agile methodologies are facing pushback.   


Tech Articles
Welcome Page