Facts and Fallacies of Software Engineering
Software engineering's growing pains
Description
In 2002, a software engineer named Robert L. Glass — a man who had already spent roughly fifty years writing code, running projects, and watching them fail — sat down to write a book that most of his industry would find mildly insulting. He called it Facts and Fallacies of Software Engineering, and it is exactly what the title promises: fifty-five facts and ten fallacies about how software actually gets built, each one stated plainly, defended, and followed by a note on how thoroughly the field ignores it. There is no grand theory in it. There is no methodology to buy. There is a tired, well-read practitioner telling us things his colleagues keep having to relearn.
What makes the book strange, even now, is how little of it has aged. Glass wasn't reporting on a passing fad or a specific language war. He was collecting the durable truths — that estimates are usually made too early by the wrong people, that the gap between a good programmer and a poor one is enormous, that maintenance eats most of the money, that adding people to a late project pushes it further behind. None of this was new when he wrote it. Some of it was decades old. That was precisely his complaint.
Because underneath the list sits a quieter observation about the trade itself. Building software feels ancient to anyone who has done it for thirty years, but measured against medicine, law, or bridge-building, it is barely out of adolescence. Its practitioners are, in the long history of professions, newcomers still figuring out what they know — and, more awkwardly, still refusing to act on the things they've already figured out.
The question we’re asking : Why does a field that produces the modern world keep forgetting what it already knows about how software gets built?What we’ll see : A working engineer's inventory of stubborn truths — about estimates, people, and maintenance — and what that inventory reveals about a profession still finding its feet.
Table of contents
01Chapter 1 — The estimates were wrong before anyone typed a line
If there is a single wound running through Glass's book, it is the software estimate. Projects come in late and over budget so routinely that lateness has stopped counting as news. Glass's diagnosis is more precise than the usual grumbling, and it lands earlier than most people look. The estimate, he argues, is almost always made at the worst possible moment — at the very start, before anyone understands what is actually being built — and it is usually made by the wrong people, namely managers or customers rather than the developers who will do the work.
So the number that a whole project gets measured against is, in Glass's telling, a guess produced under maximum ignorance by someone with minimal responsibility for hitting it. Then something worse happens. When the real work reveals that the estimate was fantasy, the estimate rarely gets revised. It hardens into a target, and the team is judged against it. A project that was proceeding perfectly well is declared a failure, not because the work went badly, but because a bad guess was allowed to become a promise.
02Chapter 2 — The best programmers aren't a little better
One of Glass's most quietly radical facts concerns the people themselves. The difference in productivity between the best software developers and the worst is not marginal. Depending on the study he cites, it runs to a factor of somewhere between five and roughly thirty to one — one person doing in a week what another does in a season, and doing it with fewer defects. This isn't a claim about heroes and slackers. Both groups are competent professionals who passed the same interviews and drew similar salaries.
Glass draws the obvious inference and then watches the industry refuse it. If individual variation is that large, then who is on a team matters more than almost anything else — more than the methodology, more than the tools, more than the programming language everyone argues about. And yet most organizations spend their attention on process and tooling, the things that can be purchased and mandated, while treating people as interchangeable slots on a staffing chart. It is easier to buy a tool than to admit that the outcome depends on which humans you hired.
03Chapter 3 — Adding people to a late project makes it later
Some of Glass's facts are borrowed, and he says so plainly. The most famous belongs to Fred Brooks, whose 1975 book The Mythical Man-Month gave the industry a line it still can't fully absorb: adding people to a late software project makes it later. The instinct, when a project falls behind, is to throw more bodies at it. Brooks explained, and Glass reaffirms, why this backfires. Newcomers have to be brought up to speed, which drains the very people who were already productive, and the number of communication channels between team members grows far faster than the number of people.
Glass folds this into a broader theme about where the effort really goes. Coding, the part everyone pictures when they imagine software work, is a minority of the job. The larger and less glamorous share lives in maintenance — the years after a program ships, when it must be fixed, adapted, and extended. By his accounting, maintenance consumes something like forty to eighty percent of a software product's total cost, and most of that isn't repairing mistakes. It's enhancement: making a working system do new things as the world around it changes.
04Chapter 4 — The uncomfortable things everyone half-knows
Step back from the individual facts and a pattern in the book becomes hard to miss. Almost none of what Glass reports was discovered by Glass. Brooks wrote about man-months in 1975. The productivity-variation studies date to the 1960s and 1970s. The estimation research had been accumulating for decades. Glass's contribution is not discovery but insistence — the act of writing down, again, things the field had already established and then quietly declined to live by. That is a peculiar thing for a book to have to do, and it says something about the discipline it describes.
What it says is that software engineering is young, in the way professions are young before they build durable memory. Medicine took centuries to make handwashing non-negotiable. Engineering codified load tolerances into law only after enough bridges fell. These fields eventually developed institutions — licensing, accreditation, hard-won consensus — that carry knowledge forward so each generation doesn't relearn it from scratch. Software has almost none of that machinery. Its facts live in books like Glass's rather than in the bones of the practice, which is why they need re-stating every few years to an audience that finds them faintly surprising.
05Conclusion
Robert Glass wrote his book as a man near the end of a very long career, and it reads like it — patient, unimpressed, done with hype. The fifty-five facts and ten fallacies never resolve into a program to follow, because that was never the point. Glass wasn't selling the next method. He was doing something rarer and less profitable: writing down what the trade already knew, in the hope that saying it plainly one more time might make it stick. The facts about estimates, about people, about the long tail of maintenance, are still cited today, which is both a tribute to the book and a small indictment of the field it was written for.
Related books
