1. 25
  1.  

  2. 10

    This book (one of my favorites) is a combination of remarkable writing and absolute truth regarding the nature of software. I pulled out a couple of my favorite passages that appear early in the book. If you haven’t read this, and work in software professionally, stop everything you are doing and go read it right now!

    … there is delight in working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exhertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. …

    And then several sections later:

    … Computer programming, however, creates with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified. …

    Absolutely marvelous.

    1. 7

      I thought this book was kinda one of the “classics” of software engineering–you know, something everyone “needs to have read”, should have on their desk shelf.

      Once I’d actually read it, though, it turned out to be a collection of very good reflections on the nature of what works and what doesn’t work in software development. It’s a useful exercise to try and spot the analogues of the time to today’s practices (for example, what has replaced the detachable binder pages he talks about?).

      Sadly, it always shows how much we’ve failed to learn in our craft.

    2. 4

      It’s really cool that this is there. It must still be under copyright, so presumably Addison-Wesley gave permission? But I can’t find any sort of thank-you for their generosity.

      Archive.org does some really important work. :)

      1. 4

        It was made available through the computer history museum

      2. 2

        While the book is well known for its discussion about scaling of the software teams, there are other essays that are rarely mentioned, and much more contentious. For example, what about the proposition that there should be one programmer with a wide variety of support staff?

        1. 1

          What exactly about “The Surgical Team” (the essay I believe you’re referring to) is contentious, rather than merely outdated? I think the computing environment that an individual programmer works within today is very different from what was contemporary when the essay was penned (circa early 1970s?).

          It’s pretty easy for me to produce and edit a README.md file now; in the past, editing and type-setting documentation was a more time-consuming task. The essay also mentions a lot of paper-based record keeping about program development and performance. I think it’s safe to say that there are now better, more powerful tools for those tasks as well – in large part because of how powerful computer systems and software have become today.

          1. 1

            like diagram on page 36?