1. 7
  1.  

  2. 4

    The phrase “software crisis” rubs me the wrong way. I’m reminded of this classic from Bertrand Meyer which points out how much working software we take for granted.

    It looks like this book might be worthwhile though.

    1. 2

      For it to be a crisis, it should also be something that’s new and temporarily, right? As far as I know, issues with software quality have been there forever.

      But Bertrand Meyer is also being a bit disingenuous - yes, we have a lot of software that’s nice, but if that’s the (say) 10% that survives and thrives there’s still 90% of projects that fail in some way or another (if it’s not technically, then financially/time-wise). It’s survivorship bias to say that everything’s fine.

      1. 3

        The software crisis was originally coined because electrical engineers were convinced that software should be the trivial, easy part of computing, and reality kept refusing to bow to their preconceptions.

    2. 3

      Would love to see a review of this once people have time to digest it. From this page I don’t get a picture of what the author thinks should be done.

      1. 3

        The business purpose of unit tests and types isn’t to prevent defects but to prevent variations in quality.

        OK, that sold one copy at least.

        1. 1

          Seems weird that the book tag is only for whole books and not ads for books.

          And another – I paid today.

          1. 1

            How is the book so far? Does it deliver?

            1. 1

              It’s quotable , but I’m only in the first chapter (rarely read during the work week)

              1. 1

                I’m in chapter seven. So far my least favorite chapter has been two. Below are my remarks on the first four chapters. I’ve been writing this summary as I go through, and I find the book very exciting. Would recommend it to anybody considering a role managing software projects or project outcomes.


                The introduction set the tone nicely. Software has always sucked and we should be able to do better.

                Chapter one. Software is not uniquely difficult. In fact it is not that difficult compared to what most companies do. Yet most successful companies ship good hardware, with bad software. See Boeing, Toyota. This is because of bad management.

                Chapter two. Companies kill morale with unrealistic demands on their people and eventually stoop to hiring indentured servants to reduce churn. This is a very weak chapter, most companies are not nearly this bad to their people. It would have been a better chapter if Parkinson had written it.

                Chapter three. The organization is the biggest source of an individual contributor’s productivity. Or failure of a team. Your process should respect people as not interchangeable, but at the same time, as sun tzu says, your plans should not depend on the excellence of your people. The author would have quoted sun tzu if he was aware sun tzu said this, but the point made is: problems arise. Either your system survives, or it needs changes. Skilled managers should not be stepping in to correct problems in reports’ work, since that hides how well the system is working. Processes in a system are feedback loops that adjust what people are doing.

                Chapter four. Software needs to care about people, but also the first rule of not killing software is “be simple.” *nix ate the world in part because it was so dang simple, it could just keep going and be implemented over and over again. I don’t know how much I buy the Unix example brought here, I would have preferred to see another example at least, to have a trend instead of a dot. Maybe simple software eats the world. Maybe it rarely does.


                I’ve been really enjoying it, even as I’m critical of some of the earlier points. Maybe I just know less about management, but I am enjoying this.

          2. 2

            Seems weird that the book tag is only for whole books and not ads for books.