[steveklabnik]

  > Edit

<3

So, what's interesting is, I would often consider many small bits to have a _lower_ cyclomatic complexity number. That is, whenever I've used tools that measure this kind of thing, the solution is always to take the big things and break them up into many, smaller bits. It's possible that this is bias in the tooling, though.

I think some of this comes down to individual preference as well. It's like that joke, would you rather fight one horse-sized duck or 100 duck-sized horses? In this admittedly very stretched metaphor, the former are relatively monolithic codebases, and the latter are relatively modular ones. I know that I used to prefer one hundred-line class to ten ten-line classes, but now, much much prefer the latter. My experience talking to people about this is that people fall somewhere on this line, often in different places, and that makes it harder to understand. The action that I'm taking to reduce complexity can often be perceived as increasing complexity, depending on where the other person falls on that line.

[slowmovintarget]

Lots-of-little-ones (LOLO? LOLO) is the right answer in a number of cases. One big god service? No; microservices (lots-of-little-ones). Large many-lined functions with copious branching and conditionals? No, LOLO. Big teams with multi-hour status meetings? No... LOLO. One big integration at the end of the project? No...

That dependency diagram for Servo actually looked relatively clean. You can clearly see which elements are library or utility code. The visualization would probably be better as a three-dimensional model with weighting.

For OO practice, state of the art is SOLID (with a sprinkling of RAII if you happen to be using C++). SOLID leads you straight down the path of LOLO. Small increments FTW.