1. 18
  1. 6

    It’s a great book and some philosophies from the book (especially around module design) have stayed with me in the couple of years since I read it.

    Highly recommend this one to anyone looking for books on software design. And it’s a super short read; I casually read it over a weekend.

    1. 3

      This is a remarkably good book review. Thanks for posting.

      1. 3

        Great philosophies and advice. But, I disagree with Ousterhout’s conclusion that TDD discourages an investment mindset. In my experience, you can be focused on long-term design and be test driven. You can write feature level tests that function regardless of the underlying technical design. Or you can write unit tests that valide the contracts of your design, effectively making test writing part of your contract definition process.

        1. 2

          Once again linking my comments on this book (this seems to come up on a regular basis). It’s a mixed bag; there’s some really interesting bits and good advice, but I wouldn’t just hand it to a new engineer without caveats.

          1. 2

            When y’all talk about TDD, what exactly do you mean? Do you mean e.g. what Wikipedia describes? Because that gives a five step process that on my reading does “it focuses attention on getting specific features working, rather than finding the best design”.

            First, it explicitly instructs you not to think too hard when writing the first implementation:

            [Step 3] Write the simplest code that passes the new test. Inelegant or hard code is acceptable, as long as it passes the test. The code will be honed anyway in Step 5. No code should be added beyond the tested functionality.

            Step 5 involves cleaning up this code, but this seems questionable: in my experience, it’s easier (but requires more up-front work) to write good code than it is to clean up “the simplest” code to an equally-good state. It can be harder to see the better perspective when you have the worse perspective sitting in front of you.

            Also, while the steps give you time for refactoring your implementation, they don’t give you time for improving your interface (which would involve updating both your tests and code, even though the old tests pass). I often find that there’s an interplay between the implementation and interface, and thus after writing the implementation I discover some ways the interface could be improved. Altogether, I think if you tried to follow this five-step process, you’d end up pretty feature driven.

            Anyways, the main point I wanted to make was that TDD means more than “write tests before code” (at least according to Wikipedia and the top search results), but not everyone realizes this, so I’m not sure if you two are defending tests-before-code or the-five-step-process, and I’m not sure whether the author is advocating against tests-before-code or the-five-step-process.

        2. 2

          Nice review!

          If you have recommendations for other good books on software design, please share it in the comments.

          Haven’t read it myself yet but I heard good things about The Practice of Programming.