Earlier quoted context omitted.
I think my issue with this generalization is assuming the code itself is where complexity is measured and applied. For example, the Quake Fast Inverse Square Root[1] takes into account nuances in how floating point numbers can be manipulated. The individual operations/actions the code takes (type casts, bit shifts, etc.) are simple enough, but understanding how it all comes together is where the complexity lies, vs j…
While the tools you talk about sound interesting, to me this was more about an in-principle possible measurement rather than something we'd actually carry out. I think stating that "more stuff" in the program code and in the spec leads to more stuff to keep track of, and so we want to minimize complexity to maintain tractability?
Re: Designing Software in the Large
#41I think that's reasonable :) More stuff is more stuff, no matter how simple/complex the aspects of the code and reasoning for why it is that way.