Measuring Software Complexity: What Metrics to Use? • Hacker News Board

Re: Measuring Software Complexity: What Metrics to Use?

#41

Post by SKILNER » Sun, Nov 28, 2021, 4:13 PM UTC

The real answers about complexity come from thinking about why we even care. It's because our feeble minds have to build internal models of the code so we can work with it. The cognitive aspects of building those models is why complexity matters.

What things make it more difficult to build those models? A partial list, mostly as others have mentioned:

- tool and library dependencies - nested conditions - loops and especially nested loops - asynchronous processing, callbacks, etc - non-descriptively named variables and functions - using non-standard code patterns for standard functionality - delocalized code, as in, you have to navigate somewhere else to see it (throws off your working memory)

By one study, developers using Eclipse for Java spent 27% of their time just doing code navigation.

The starting point for code complexity is about how our minds work.

As many people have said, "it's easier to write a program than read it."

Re: Measuring Software Complexity: What Metrics to Use?

#42

Post by [deleted] » Sun, Nov 28, 2021, 4:18 PM UTC

SKILNER wrote: post #41

The real answers about complexity come from thinking about why we even care. It's because our feeble minds have to build internal models of the code so we can work with it. The cognitive aspects of building those models is why complexity matters. What things make it more difficult to build those models? A partial list, mostly as others have mentioned: - tool and library dependencies - nested conditions - loops and es…

[deleted]

Re: Measuring Software Complexity: What Metrics to Use?

#43

Post by exabrial » Sun, Nov 28, 2021, 4:24 PM UTC

The number one metric: Consistency. If an app is similar to itself in all places, it's very easy to understand. Better yet, if it's similar and consistent with how other things have been built, we can call it "clean code".

Back in the day we called these things architecture, but I'm old and salty.

Re: Measuring Software Complexity: What Metrics to Use?

#44

Post by pfdietz » Sun, Nov 28, 2021, 4:35 PM UTC

There were attempts to predict bugs by looking at complexity metrics. As I recall, the research found that when you adjusted for code size, none of the metrics mattered. In other words, just use LOCs as your metric.

Re: Measuring Software Complexity: What Metrics to Use?

#45

Post by vinodkd » Sun, Nov 28, 2021, 4:48 PM UTC

sam_bristow wrote: post #4

The last section on coupling reminded me of the concept of connascence[1] which I've found really helpful when talking about code. [1] https://connascence.io

Thanks for this link. TIL. Also, the videos linked from the site were useful

Re: Measuring Software Complexity: What Metrics to Use?

#46

Post by tromp » Sun, Nov 28, 2021, 5:02 PM UTC

cryptica wrote: post #26

okl wrote: post #25

Earlier quoted context omitted.

I think you applying that definition in your way to the issue of source code complexity is outlandish.

Why is it outlandish? You're confusing the reliability of using source lines of code as a metric for measuring the productivity of developers with measuring the complexity of a system. It's a bad metric for measuring productivity but a good metric for measuring complexity. The problem with using lines of code as a metric for developer productivity is precisely that it leads to developers introducing unnecessary compl…

It may be outlandish because minimizing the number of bits, when taken to the extreme as in Algorithmic Information Theory, leads to very obfuscated code [1].

[1] https://www.ioccc.org/2012/tromp/hint.html

Re: Measuring Software Complexity: What Metrics to Use?

#47

Post by juancb » Sun, Nov 28, 2021, 5:38 PM UTC

hacoo wrote: post #7

Ugh, no. I’ve worked in a codebase where CI would reject changes that had too much ‘code complexity’. You’d constantly have to find clever ways to split up your code, when doing so did not make sense, to appease the complexity checker. Oh yeah, and if you ever make a one-liner change, you might end up being forced to do a full refactor because that one line pushed the complexity threshold over the edge. The results:…

Did you also have the same feedback from your IDE?

In other words would it have been less painful if you didn't have to suffer the long iteration times required to get feedback from some remote CI job?

Re: Measuring Software Complexity: What Metrics to Use?

#48

Post by juancb » Sun, Nov 28, 2021, 5:42 PM UTC

throwaway81523 wrote: post #10

Some blog linked from here (maybe jvns.ca?) made the case that depth of your project's software dependency tree is an important metric. The more crap you have to pull in, the more things can go wrong. You're better off with a large program with no dependencies, than a somewhat smaller program with a ton of dependencies. Language features on the other hand can let you develop complex programs quickly and reliably, by…

What about the depth of dependencies of any part of the standard libraries for a given language?

Re: Measuring Software Complexity: What Metrics to Use?

#49

Post by drewcoo » Sun, Nov 28, 2021, 5:44 PM UTC

flaratt_ljos wrote: post #6

There are a lot of things you can do to lower these sort of metrics without addressing actual complexity, sweeping the problem under the rug. Perhaps a better metric for software complexity would be the amount of work the computer has to do, or the number of instructions it has to execute.

The problem is not computer processing speed. The problem is human cognitive load.

Re: Measuring Software Complexity: What Metrics to Use?

#50

Post by ok_dad » Sun, Nov 28, 2021, 5:56 PM UTC

One thing I hate is having like 20 different Python repos for one small company. At most places I've worked at, you have basically one thing you do business-wise, but it's split into what I believe are arbitrary repo delineations. This causes trouble with dependency resolution in your build systems and IDEs and increases cognitive load and merge complexity for changes across repos.

Just put the whole folder structure into one repo! This would reduce build complexity, and you can set up the configs for your tools and CI one time rather than 20. You can still have several services out of one repo, if you want to, but it's easier to reason about and easier to change those service delineations later, where in 20 repos you're having to "clone and cut code" to separate things. In one repo, you just move code around as you split or merge services.

I routinely create a "super repo" for myself at these companies using submodules, so that I can actually work with the code more easily, but that still requires me to check in maybe 5 or more PRs for one feature, so it's not ideal. This only solves the developer's problems with local tools and still requires more complex debugging since the services are not actually in one repo under one config for deployment.