software

Subtitle: An Agile Primer

Recommended to me by: Sam Livingston-Gray

While there was a lot of useful information in this book, I kept tripping over basic information presented in what struck me as condescending ways. It is possible to write for novices without assuming they are stupid.

I liked the extended example of planning a bicycle tour, complete with realistic details. It’s easier to read examples where I’m familiar with the domain and get the in-jokes.

I appreciated the emphasis on evaluating costs. If it costs a lot of time and money up front to design carefully, and those costs are never recouped, then the effort spent on design was not cost-effective.

Plan for future changes, but don’t try to anticipate them. Postpone decisions until you have more information, but isolate your assumptions to just one place in the code so you’ll be able to change them later.

The refactoring advice in this book seems targeted at small to medium-sized systems. She suggests that an inheritance hierarchy should be either deep or wide but not both, but does not offer alternatives for managing a system that doesn’t fit within those constraints.

When using inheritance, use hooks called from the parent class so that the child class does not have to call super in just the right way.

She advocates for composition over inheritance, using Forwardable to let an object respond to a contained object’s methods.

The patterns for reusing tests to match reused code look very useful. When you include a module in a class, include a test for that module in the test for the class. Test only the public interface of a class – its private methods are its own business. Test the state changes caused by incoming messages. Test outgoing commands with mocks of their recipients.

Recommended if you’re new to object-oriented design, or if you want to learn about some Ruby-specific design patterns, or if your coworkers quote heavily from this book.

Available at bookshop.org.

Recommended to me by: Sam Livingston-Gray

This book conveys tips, tricks, and cautions in a conversational style without talking down to the reader. Several topics became immediately useful when I recognized them in the code at work the next day.

Some of Ruby’s oddities, I mean special features, are:

• No static type-checking. Pass any object as an argument to a method, and if it answers to the methods called on it, all is well. This is formally known as “duck typing,” as in “if it looks like a duck, and quacks like a duck…”
• Pass anonymous blocks to functions. For example Array.each will call a block on each element of an array.
• Add/change/delete methods in classes at runtime.
• Mix in new functionality by including modules in a class.
• Override method_missing to extend a class on the fly. This is considered a “standard” trick.

Highly recommended if you’re programming in Ruby. I’d read Russ Olsen’s writing on any topic based on the quality of this book.

Available at bookshop.org.

Recommended to me by: Sam Livingston-Gray

This book is written in a more formal, technical style than Test-Driven Design by Example. I’m glad I read the latter book first.

The main new idea I learned from this book is to set up a testable skeleton of a new application at the beginning. This involves researching infrastructure decisions up front, as well as dealing with the thorny issue of installation. The authors’ point is that this work has to be done at some point, and it makes project schedules a lot more reliable in the long run when it is done first.

The authors advocate for making software objects small and shifting emphasis to the communication between them.

Available at bookshop.org.

Recommended to me by: Sam Livingston-Gray

Test-Driven Development (TDD) is a tool to manage the complexity and difficulty of writing software. It offers an alternative to the “waterfall” approach: design specification, functional specification, implementation, testing, release. In theory each step is finished before going on to the next. The problem is that there is a whole lot of debugging during and after implementation, testing, and release.

In TDD, the programmer writes a test for one small aspect of a program, then implements the minimum code required to satisfy that test. Once the new test passes, the code is refactored to remove duplication while still passing all tests. Repeat as needed. In this way, designs evolve to satisfy existing conditions rather than guessing about what’s needed months or years in advance. In addition, the code is always in a working state.

This is the most conversational software book I’ve read. It’s like having the author next to you at a computer, explaining the steps as you type. After years of battling waterfall development cycles, I’m convinced TDD is a useful approach, and I’m eager to try it.

Available at bookshop.org.