Tag: book club

Categories
Review

“Modern Software Engineering”

David Farley

Over the course of reading this book, I kept coming back to two thoughts.

Firstly, I think Farley undersells the advances that programming languages have made. He has a point that the level of bikeshedding about languages that programmers are capable of is too much, but treating it as completely nothing is throwing the baby out with the bathwater. Take an example close to my heart: comparing Objective-C and Swift, there have been some significant advances. The introduction, and use throughout the language and libraries, of optionals has functionally eliminated null-pointer exceptions. Memory management bugs are a massive category of problems, across all sorts of software. Look at Heartbleed, for example. If you’re using Swift idiomatically, and avoiding the (hilariously named) UnsafePointer stuff, this sort of problem cannot happen.1

Secondly, this book felt like the moment where in my mind I went “oh, we are getting there.” He makes a point early on that software engineering as a field has different standards of success than other engineering disciplines. Again, an example: this morning, I woke up to a truly terrible software bug in an app I use that had deleted several years worth of data. This is a bad bug, and I’m personally quite upset about that loss, but it’s not as bad as, say, the Tacoma Narrows bridge collapse. Subjectively, it feels like software as a whole has a lower bar for “is this okay to produce” than the other, physical engineering disciplines.

Where this book changed my opinion is in starting to feel like the field is beginning to coalesce around some standards. We’re nowhere near the level of “you have to use these techniques, and if you don’t you can lose your Software Engineering License and be prohibited from working professionally in the field,” but some of those techniques are taking shape.2 Farley’s argument is that the core of it is fast feedback, allowing for tight iteration loops, and from that it logically follows that test-driven development is the best option.

And yes, I’m sold! Just the other day, while doing some tinkering on a personal project, I found several bugs I’d created — because the tests I wrote before I started writing the code failed. That’s such a nice way to do things. And now, having written both the code and the tests, I feel much more comfortable with the idea of “oh, I’m going to need to reuse some of this logic somewhere else, I’ll just pull it out into a separate chunk.” I don’t have to spend an hour thinking through “what might break from this,” or testing things out. I just do it, run the tests, and know that I’m good.

As to the book itself: he’s hammering the same points over and over, as these sorts of books tend to do. I found it a generally good read, and took many notes for the book club discussion, but I don’t know that it was particularly world-changing… or if anyone else will have the same “eureka” feeling from it that I did. That moment came with a very clear sense of “all the other stuff I’ve read and done leading up to now came together into this idea.” It’s not a bad book, though, and could be a pretty good starting point if you’re just getting into the “read about the field” kind of thing, so check it out.3

  1. And I’m also setting aside the type checker, which is, for all intents and purposes, a form of mandatory unit testing imposed at compile time. Writing Swift, you don’t have to safety-check your inputs to make sure they’re the right types; the language does it for you. ↩
  2. I do absolutely believe that software engineers should be forming some kind of industry group and establishing shared standards for what “software engineering” actually means. ↩
  3. 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. ↩
Categories
Review

“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. ↩
Categories
Review

“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. ↩
Categories
Review

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