Books for software engineers and managers

The Problem with Software

The Problem with  Software

Why Smart Engineers Write Bad  Code

by Adam Barr, Formerly in Engineering Excellence at  Microsoft

Tech Lead,
Star Engineer,
New Engineer

How strongly do I recommend The Problem with  Software?
7 / 10

Review of The Problem with Software

What do I like about this book?

  • For junior engineers, you’ll learn about the history of languages like FORTRAN, C, and C++
  • I learned more about the works of popular figures in computer science and software engineering like Edsger Dijkstra, Fred Brooks, Donald Knuth, and Harlan Mills
  • The author quotes many other books, so you walk away with a list of new reading recommendations
  • The last three chapters are particularly interesting and readable, covering agile, empirical research, and academia vs. industry. I would rate these chapters a 9/10.

By volume, code is mostly error handling and  prevention

So much code we write is simply checking if the thing you previously called worked correctly or if you have the right data to proceed. Exceptions improve this somewhat, but still feel voluminous.

Code readability is more important in agile than  waterfall

In a waterfall process like the ones used to ship software on CDs or floppy disks in yesteryear, code didn’t need to be as readable because maintainability wasn’t a primary concern.

Today with server run code and agile processes, we expect to continuously work on the code and in this environment code readability is more important.

We need empirical research on software  engineering

Software engineering is somewhat poorly named because unlike other engineering disciplines, we lack empirical research on our work.

Or as the author puts it, we have some empirical research but industry doesn’t pay attention to it.

Instead we rely on our own experience and stories from others about what works and what doesn’t.

Academics are no longer strong  programmers

Academics typically working on small codebases that don’t require maintenance and don’t face time or budget constraints. This failure to work on problems similar to industry means that industry ignores academia.

As a self-taught engineer, this gap between industry and academia felt apparent when I read A Philosophy of Software Design by Stanford professor John Ousterhout. Some of the recommendations he made felt entirely disconnected from the realities of modern software engineering, especially those regarding code comments.

The history of software is looking for silver  bullets

Structured programming, OOP, design patterns, agile, functional programming, the list goes on. We’ve always been in search of silver bullets.

Where the author hops on the “No Silver Bullets” bandwagon, I swing the other way. I know silver bullets don’t exist, but I enjoy the ambition and hope of searching for them.

The Problem with Software