The Problem with  Software

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.

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.

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 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.

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.