1. 8
  1. 3

    I’m missing Lehman’s laws of software evolution, at least the first two:

    (1974) “Continuing Change” — a system must be continually adapted or it becomes progressively less satisfactor.

    (1974) “Increasing Complexity” — as a system evolves, its complexity increases unless work is done to maintain or reduce it.

    1. 1

      One caveat, though, is the “Yo Momma Corollary”: only the author is allowed to criticize the code; any other negative feedback is dismissed.

      I LOLed at that one

      1. 1

        re: conway’s law

        i think you can work around this to some extent:

        • have more components than people (an order of magnitude or so?)
        • avoid “utils” and other catch-all dumping grounds
        • have your components be searchable

        you’re still going to get libraries/tools/etc. that follow org structure, but you can get a lot outside of that structure too, and that’ll be more reusable

        1. 2

          Why work around it? Isn’t the purpose of Conway’s Law to accept the inevitable rather than fight it?

          FWIW I’ve worked in an environment that follows your suggestions and it still followed Conway’s Law.

          1. 1

            Yes. This goes beyond software, too. The way to exploit Conway’s law is to shape the organisation after the system you desire to build. This implies things like smaller, cross-functional teams* with greater responsibility (in order to get less coupling between system components). That way you maximise communication efficiency.

            * Lean people would advocate that the team should be co-located too. The idealist in me still clings to the Microsoft research that showed org chart distance mattered orders of magnitude more than physical distance.