1. 39

  2. 17

    The following comment on the orange site deserves to be amplified. It’s something I’ve been saying for a while, but not this eloquently.

    Since communication overhead increases proportionally the square of the number of people on the team—a fact illuminated by Brooks in the 1970s—what you actually want is as little collaboration as you can get away with. It’s an important point that warrants repeating. It comes from an observation that if there are N people communicating directly with each other, every one has to communicate with N-1 other people, which leads to N*(N-1)/2 simultaneously open bidirectional communication channels, which is O(N^2). I think this point plays a crucial role in why hierarchies form, both in teams/companies and societies. A hierarchy is what lets you turn an O(N^2) relationship into O(N) one, at the expense of creating O(log n) hops.

    1. 4

      Coda Hale covered this pretty eloquently in the post “Work is Work” last month:


      With the punchy takeaway: “Keep the work parallel, the groups small, and the resources local.”

    2. 7

      Features don’t work, in the sense that they can be easily gamed. A brittle and perfunctory implementation, done quickly, is going to score more intramural brownie points over a robust and complete one. If the question is “does product A have feature X?” then the answer is yes either way. This also makes features a spurious basis for comparison in competing products because you need to seriously examine them to determine the extent to which they are any good.

      I know this is not the main things intended to be drawn from the article, but as someone who hasn’t worked in any “methodology driven environment” for a long while, this still rings pretty true to me.

      It’s an issue that extents beyond agile to most methods of development, most of them are feature based, it’s come to be the universal currency of software development.

      But I don’t think this can be easily addressed, not until the market comes to term with the fact that more features usually means worst core functionality. But sadly enough I think this extends to a broader theme of programming illiteracy.

      If you want users to address their requirements in terms of behavior the users are now doing testing a defining exact specifications, but in my experience that’s more than half the work with a lot of projects in the real world, rather than in the abstract world where there’s this mythical “user that knows exactly what they wants” creature.

      1. 2

        This is made worse because often the person/team selecting the software to purchase is only a small portion of, if even related to, the actual end users of the software.