1. 22
  1.  

  2. 2

    https://blogs.msdn.microsoft.com/philipsu/2006/06/14/broken-windows-theory/

    Windows code is too complicated. It’s not the components themselves, it’s their interdependencies. An architectural diagram of Windows would suggest there are more than 50 dependency layers (never mind that there also exist circular dependencies). After working in Windows for five years, you understand only, say, two of them. Add to this the fact that building Windows on a dual-proc dev box takes nearly 24 hours, and you’ll be slow enough to drive Miss Daisy.

    I haven’t been around in the industry too long, i was in school when this blog entry was posted. But I’ve seen a few projects struggle and fail because of bad architecture and increasing technical debt. The OPs article definitely reflects the struggle between new features, legacy support, and paying down the technical debt (improving security, etc.).

    1. 2

      The microservices that are all the rage these days adds a whole new layer of challenge to understanding dependencies. While monoliths have their own challenges, at least all of the information is there to understand what is connected. I’m still not sure if this has been adequately solved.

      1. 2

        Arguably microservices can simplify this dependency tree tremendously. In the world to date, it has been essentially impossible to compile many differently versioned libraries together into one monolithic application, which is what generally happens when you have a large number of teams doing separate development.

        With microservices, again arguably, encapsulation happens at the whole-service layer, so each team is free to develop using whatever versions they like, and just provide HTTP (or whatever) as their high level API.

        Where this tends to break down in my experience is (a) where true shared dependencies exist, which can happen if you either were bad at data modeling to begin with or if your needs organically grew differently than your original design, and (b) operationally, in a world of incredibly broken and insecure software, processors, etc., resulting from C (and now JS) and the shared memory model, where it is no longer possible to understand what in the opaque blobs need patching.

        1. 1

          C obviously has memory bugs but I’m curious what insecurity you see stemming from JS. Is it the automatic type casting? (I write JavaScript every day and think a good portion of the new parts of the language are good, but I will fully admit it spent its formative years on crack.)

          1. 1

            I don’t see how adding more dependencies simplifies anything, that can only make it more complicated. It may be convenient, but it’s not simpler. And in order to have that architecture one needs to have network protocols and serialization going on which has a performance and cognitive cost. There certainly are reasons to have a microservice architecture but I have a hard time seeing simplification as one of them.

          2. 1

            Microservices exist mostly to facilitate development by many teams on a large system. They are one of the best examples of Conway’s Law.

            You are correct that they add complexity, and they tend to be adopted regardless of if they solve a real problem.