Anthony Abbott

Summary

Robert Glass’s Facts and Fallacies of Software Engineering is a sharp, compact book that aims to cut through hype and wishful thinking in the software industry. Drawing on decades of experience, Glass distils key insights into two categories: facts—observations backed by evidence and expertise—and fallacies—commonly held beliefs that don’t hold up under scrutiny.

The book’s central argument is clear: the quality of people matters more than the quality of tools or processes. Great programmers outperform poor ones by enormous margins, and most software failures stem from unstable requirements, poor estimation, and unrealistic schedules, not from a lack of methodology. Glass also revisits Brook’s Law, reminding us that adding people to a late project often makes it later.

Glass is sceptical of silver bullets. He argues that tools are often overhyped, sometimes used once and discarded. He advocates for a rational, experience-based approach to estimation and planning, where technical staff—not managers—do the estimating, and where estimates are revised as the project evolves.

In a field often obsessed with innovation, Glass’s message is refreshingly grounded: get the basics right, value your best people, and don’t chase fads.

Key Insights

The first and most important message of Facts and Fallacies of Software Engineering is that there is no silver bullet. There is no magical methodology, no breakthrough tool, and no universal technique that can solve the inherent difficulties of software development. While new tools and methods may help incrementally, they rarely deliver the dramatic improvements their proponents claim. Most are used briefly and then abandoned. In the end, success depends less on what we use, and more on who is doing the work.

Glass argues forcefully that the quality of the staff is the best predictor of project success. Great programmers outperform poor ones by wide margins—he cites a 28-to-1 performance ratio—and yet organisations continue to place more emphasis on tools and processes than on hiring and retaining excellent engineers. It’s not that tools are irrelevant, but that they are secondary.

Another key idea is the importance of stable, well-understood requirements. Most project delays and failures arise not from poor coding or flawed architecture, but from missing, changing, or poorly communicated requirements. Estimations based on unclear goals are doomed from the start. Glass urges teams not to estimate until the requirements are known, and to adjust those estimates as the project evolves. When schedules are based on politics rather than reality, quality inevitably suffers.

In short, Glass promotes a grounded, people-centred, and experience-informed approach to software development—one that values realism over optimism and expertise over fashion.

Strengths

One of the book’s greatest strengths is Glass’s emphasis on stable requirements and realistic schedules—a message that remains as relevant today as when the book was written. He is clear-eyed about where most projects go wrong: not in coding, not in design, but in poor estimation and shifting requirements. When developers are asked to commit to timelines before the work is understood—or worse, when estimates are dictated by managers to satisfy external pressures—the result is nearly always failure, delay, or a collapse in quality.

Glass is also right to insist that estimates should be made by the technical staff doing the work, not by those with political agendas. His call for rational planning, grounded in real understanding, cuts through the wishful thinking that too often characterises software project management.

By focusing on these often-ignored basics, Glass reminds us that discipline, clarity, and realism matter more than buzzwords and new tools. His writing is pragmatic and seasoned by long experience, offering timeless advice to developers, managers, and stakeholders alike.

Weaknesses

The main weakness of Facts and Fallacies of Software Engineering is that it is, in many ways, a pre-Agile book. Glass rightly emphasises the need for stable, well-understood requirements—but in doing so, he assumes a model of development where requirements are largely defined upfront. This aligns more closely with the waterfall methodology, which has since fallen out of favour.

In today’s Agile-dominated landscape, changing requirements are not only expected but embraced, provided they are managed with discipline. Iterative delivery, user feedback, and adaptive planning now form the core of modern software practice. While Glass’s insistence on clarity and stability still holds merit, his framing may seem outdated to readers working in Agile environments where continuous change is the norm.

That said, his more profound message—that poor estimation, unrealistic schedules, and unmanaged requirements are project killers—remains valid, even if the context has evolved.

Reflections

There is much in Glass’s book that resonates with me. I’ve seen firsthand the damage caused by unstable requirements and unrealistic schedules. On one project, the requirements changed dramatically—just two weeks before go-live. The schedule had been drafted not by the development team, but by managers responding to pressure from the sales department, who had effectively pulled a deadline out of the air.

The result? Poorly tested, rushed software, and when things went wrong, the developers got the blame.

Glass’s insistence that technical staff must set the schedule, and that requirements must be stable before meaningful estimation is possible, felt less like theory and more like a description of what I wish had happened. His experience-backed perspective helped confirm what many developers already suspect: that many of our biggest problems are organisational, not technical.

Conclusion

Glass ends his book with a challenge: we should assess our tools and methods based on evidence, not fashion. How do we know Agile is better than Waterfall? Does a new tool truly improve performance, or is it just a distraction? In a field prone to hype and silver-bullet thinking, Glass’s call for measured, empirical evaluation is both timely and necessary.

He rightly tilts at the overblown promises of many tools and methodologies, reminding us that no technique is universally effective, and few are rigorously tested. His book is a call to be more thoughtful—more sceptical—about what we adopt and why.

Facts and Fallacies of Software Engineering is not a manual for modern Agile teams, but it remains an essential read for anyone who wants to understand the recurring failures—and persistent truths—of software development.

Book Details

Title: Facts and Fallacies of Software Engineering
Author: Robert L. Glass
Publication Year: 2002
Genre: Software Engineering, Programming
🔗 Buy on Amazon