“Perfect Software And Other Illusions About Testing”

Gerald M. Weinberg

Another book club entry, and a shorter one than usual, it feels like. I think the core concept is a good one to hold on to: testing everything is impossible, so you should be aware of what tradeoffs you’re choosing, and pick the ones that best meet your needs.

There’s some places in the book where, coming at it with Programmer Brain, I was annoyed at how long it took to explain something. Like yes, of course, you can’t test every possible system state, even just looking at a single small program there’s likely to be thousands of possible states, and that’s without addressing all the additional states created by the fact that programs don’t exist in isolation. The system they’re running on can impact them; the person using them can have a varying level of knowledge on using the program or the system; the program can be left continuously running for a long time, getting into ever more-complex possible states; heck, even cosmic radiation can impact program state.1

That complaint aside, there’s still a lot of useful ideas in there. Remember, the testers are not the enemy! But neither are they infallible. They are, in point of fact, people. Have empathy for them.

In all, a good, and reasonably quick, read about the software development process. Give it a go if that’s your type of thing.2

  1. Seriously, cosmic rays flipping bits inside RAM (or on various forms of longer-term storage media) is a real problem!
  2. This is an Amazon affiliate link – if you buy it from here, I get a little bit of commission. It won’t hurt my feelings if you buy it elsewhere; honestly, I’d rather you check it out from your local library, or go to a local book store. I prefer Bookshop affiliate links to Amazon when possible, but in this case, the book wasn’t available there, so it’ll have to do.

“The Culture Code”

Daniel Coyle

I’ve been enjoying that the book club at work seems to bounce back and forth between books that are Very Programmer-Oriented and things that aren’t at all specific to programming. This time, it’s the latter, despite the word ‘code’ in the title: The Culture Code is, in fact, more of a management book.

The focus is, as you might expect, on culture. What is a culture of success/productivity/various-other-positive-buzzwords? How do you create one?

Very broadly, the answers are: “one in which people feel safe and can feel vulnerable, and do is in the pursuit of a shared goal”. As for creating that environment, well, that’s what the rest of the book is about. And, generally, the tips boil down to “show people that these things are the case.” Make people feel safe by showing that they belong, that they are part of the in-group of this culture. Demonstrate that it’s okay to be vulnerable by making yourself vulnerable, showing your weaknesses. And reiterate the shared goal… mostly through use of little catchphrases, seems to be the advice there. It does feel a little trite, but then, having those little catchphrases repeated over and over does seem to hammer them into one’s head.

I actually did find there to be a good bit of value in this book, but in that “useful self-help book” way, where there’s the broad topic that you could’ve fit on an informational pamphlet, and then there’s the rest of the advice, which is scattered around in a way that feels almost like one of those little daily desk calendar things. My pull-quotes notebook lost several pages to this book.

So, overall, I found this a good book to read! I think it is, perhaps, uniquely well suited to be a Workplace Book Club read, and could happily suggest it as the first book for starting one of those up if you don’t have one already. Give the book a go.1

  1. This is a Bookshop affiliate link – if you buy it from here, I get a little bit of commission. It won’t hurt my feelings if you buy it elsewhere; honestly, I’d rather you check it out from your local library, or go to a local book store. I use Bookshop affiliate links instead of Amazon because they distribute a significant chunk of their profits to small, local book stores.

“Test Driven Development by Example”

Kent Beck

‘By example’ books really aren’t my cup of tea—going back and forth between a book and the actual thing in order to follow along is too much overhead for either activity to work well, and just reading along without doing it myself leaves the book feeling rather anemic a lot of the time. That said, this book wasn’t terrible; I enjoyed Beck’s writing style throughout the whole first part, he did a good job livening it up with some personality so it didn’t feel like reading a WikiHow article. But where my interest really kicked in was in the third part, where it switched to more of a traditional Programming Book style, just dispensing a bunch of condensed advice.

There’s some good little tidbits in the earlier part, though; I think my favorite one was:

[Automated] tests are the Programmer’s Stone, transforming fear into boredom.

A great way to think about it! Write tests so that instead of worrying something will break as you continue working on it, you just go ‘meh, now I’ve gotta wait for the tests to run.’1

This was a quick read; if you’ve been doing some form of TDD, it probably won’t continua much that’s new, but it’s a nice way to get an overview. And if you aren’t doing TDD, go ahead and read it; as I said, it’s quick, and Beck makes a better case for TDD than I will in a single blog post. It’s available in the O’Reilly Library.

  1. Although, ideally, it’s not much of a wait – this is the benefit of unit tests, in particular, that you make them small and very quick to run, and with that you’re able to run the relevant segment of them after every change.