Trying to continue the new year's resolution. The second book is The Problem With Software by Adam Barr. This is an entertaining history book on how the job software developer came to be. It's a great read, and with such a great title, how can't it be? Here follows my loosely coupled notes and reflections from reading it.

The first few chapters is a retelling of the author's coming of age with technology, education (or lack-thereof) and early career. This takes place in an era we've seen on TV. When students spent their nights at the campus's computer labs, talking to the mainframe, when the acronym PC was new and still meant something. The story starts down a path, connecting how short variable names, used in code printed in magazines set us down a slippery slope of bad engineering practices.

The book follows a chronological order and one of the earlier chapters brings up the topic of GOTOs. The author quotes Dijkstra's famous letter:

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost best to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

This is exactly the argument I like to make against exceptions (only I'm not as eloquent) - they decouple the process from the program, making it hard, if not impossible to keep everything in one human mind, for anything but the most elementary programs. I get strong flashbacks to an old university lab, working with Continuation Passing Style programming and what a brain twister that was. As is debugging Event Driven Microservice Architectures today. Despite this display of insight, the author goes on in a later chapter that Exceptions are actually a good thing? Disagree.

And speaking of disagreeing, the author also does not seem to be very fond of Code Reviews. And I mean - if there is one thing that is established as good practice, it surely is code reviewing?

The book also touches on the subject of the word bug. I wholeheartedly agree that it is overused. I honestly hate when it's used as "not expected by the user". I much more appreciate the suggested definition "surprises to the programmer". Because if the code doesn't do what the programmer expected it to do - how on earth would it ever do what anyone else expected of it? Like how (old) Date APIs use 0-indexing for months but 1-indexing for days, that's just crazy. A great source of bugs. Even the much better word: Defect, is not perfect. As a defect still needs to take into the account the environment in which it operates. At least a little.

A consistent theme for the book is how programmers are essentially self-taught. Not even at the university level do they teach how to code. The program is always second to the algorithm or other topic in question. As a student you rarely, if ever, get any comments on say.. the maintainability of your code. I guess this all boils down to the fact that there are no established metrics for quality.

Another great part of the book is the changing role of testers and testing in the industry. The concept of "throwing it over the wall" and the terrible corporate culture it leads to is explained in great detail. The fact remains that you generally cannot throw user end tests at a piece of software and expect quality to become great. This instantly reminded of this great video over on Destroy All Software which talks about the different ideologies surrounding this.

One takeaway is the great analogy of API design and organizing a hardware store. If the stuff is arranged the way you want it to be, you'll think it's a great idea - but to someone else, trying to accomplish something else - it might be a nightmare.

Another great thing about the book is how it has not forgotten that programmers are people. A special breed of people, but people nonetheless. (Also, yes, not everyone fits the stereotypes etc. But stereotypes arise for a reason.) People with a desire to be good at, and appreciated for their work. People who loves solving complicated technical problems, providing quick and efficient solutions, and above all else - doing cool and clever stuff.

The whole topic on the lack of formal education deserves its own blog post. Look forward to that. :)

I haven't actually finished the book yet. I've still got a few chapters to go - but I felt I had to get this blog post out today.