Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring Software Complexity: What Metrics to Use?

thevaluable.dev

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Measuring Software Complexity: What Metrics to Use?

#71

Post by preseinger »

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.

> 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.

Complexity is a measure of human difficulty in comprehension, not mechanical difficulty in execution...

Re: Measuring Software Complexity: What Metrics to Use?

#72

Post by tharkun__ »

jackblemming wrote: post #60
oblak wrote: post #57

Earlier quoted context omitted.

What if the code is consistently crappy and complex all around. Would that make it simple? Trick question, old man. It would not. I am not exactly young but damn I am sweet

You're not wrong. "Consistency" is a poorly defined principle and basically used to justify "what I'm doing is good (consistent). What you're doing is bad (inconsistent)" And it was called Uniformity back in the day, not "architecture". A better name for "consistency" is "following project conventions" which IS well defined.

I agree that consistency is good in general. I don't think "project conventions" is well defined.

In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to push his opinion through.

I personally like to be 'locally consistent'. I don't care how old and crusty the code base is. If the file that I have to change or add to calls everything a "giraffe", I will call my stuff "giraffe" as well, even if it really is a "gorilla". If I start calling it a gorilla, nobody will understand that the gorilla is the same as the giraffe if they don't have the same background knowledge I have. Unless I do a refactoring and I am changing the giraffes to gorillas. Which might either be a first PR to "clean up" or a follow up PR.

Unfortunately I see so many people not doing that and it wreaks havoc with the code base. Especially if we're now outside of the place that defines the giraffes and gorillas. It's really hard for the caller to figure out that they're one and the same thing.

Re: Measuring Software Complexity: What Metrics to Use?

#73

Post by kristov »

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…

Not just build internal models of the code, but also an internal model of the execution of the code. For example, a mental model of the scoping rules. As a developer you have to read a function and build a model of when variables are assigned values - you have to execute the code in your head to understand what the state will be at a particular point in time. I think a big part of complexity is having to imagine what the current in-flight state is - the larger the current in-flight state, the harder to reason about how the code will interact with it.

Re: Measuring Software Complexity: What Metrics to Use?

#75

Post by jackblemming »

tharkun__ wrote: post #72
jackblemming wrote: post #60

Earlier quoted context omitted.

You're not wrong. "Consistency" is a poorly defined principle and basically used to justify "what I'm doing is good (consistent). What you're doing is bad (inconsistent)" And it was called Uniformity back in the day, not "architecture". A better name for "consistency" is "following project conventions" which IS well defined.

I agree that consistency is good in general. I don't think "project conventions" is well defined. In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to p…

>In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to push his opinion through.

So either admit your project doesn't have conventions, in which case, don't nit people who don't follow whatever convention exists in your head but isn't documented, or document the project conventions. You cannot have your cake and eat it too.

That "one guy updating the text" is at least explicitly documenting expectations.

Per your "local consistency" comment, if "giraffe" is called "gorilla" in every other file (aka "global consistency"), it sounds like you're just setting up more work for some developer to take care of. Consider leaving a comment and start using the globally consistent name, rather than propagating more inconsistency (technical debt). Perhaps more aptly put, what you call "local consistency" sounds like "global inconsistency" to me.

Re: Measuring Software Complexity: What Metrics to Use?

#76

Post by tharkun__ »

jackblemming wrote: post #75
tharkun__ wrote: post #72

Earlier quoted context omitted.

I agree that consistency is good in general. I don't think "project conventions" is well defined. In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to p…

>In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to push his opinion through. So either admit your project doesn't have conventions, in which case, do…

Oh I absolutely agree with that statement. If you have someone in your place that is actually just documenting what everyone is doing and what everyone is doing is consistent, that's awesome! More power to them.

At my current place we do a lot through linters and automatic code formatting for example and we collectively agree on when and how to change the configs for that. Eliminates a whole class of "arguments" (X spaces vs. tabs anyone?) and it's relatively easy to "convert" new hires to it as well. They can either adapt to it, make a really good argument for changing the configs via a widely circulated PR or they aren't a cultural fit to us.

My point is that this guy usually isn't. In the vast majority of places I've been or seen it's the other version of him. I.e. the equivalent of the guy at the regulars table that edits Wikipedia to prove his point in a discussion.

Re: Measuring Software Complexity: What Metrics to Use?

#77

Post by closeparen »

throwaway81523 wrote: post #54
juancb wrote: post #48

Earlier quoted context omitted.

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

I think that doesn't count, as long as the install is in one piece. That's how Python got its popularity. Its "batteries included" approach meant you got lots of stuff in the stdlib instead of having to chase it all over the interweb. Unfortunately they seemed to have abandoned that approach in more recent times.

Python has a lot of batteries included, but nearly everyone finds it necessary to bring in “requests.” And then once you have one pip package, what’s a few more?

Re: Measuring Software Complexity: What Metrics to Use?

#78

Post by throwaway81523 »

closeparen wrote: post #77
throwaway81523 wrote: post #54

Earlier quoted context omitted.

I think that doesn't count, as long as the install is in one piece. That's how Python got its popularity. Its "batteries included" approach meant you got lots of stuff in the stdlib instead of having to chase it all over the interweb. Unfortunately they seemed to have abandoned that approach in more recent times.

Python has a lot of batteries included, but nearly everyone finds it necessary to bring in “requests.” And then once you have one pip package, what’s a few more?

I use urllib instead of requests just to get rid of a dependency. It does all the same stuff with slightly uglier calls. More to the point, Python Central seems to now favor shovelling off stuff to external dependencies.

Re: Measuring Software Complexity: What Metrics to Use?

#80

Post by worik »

epylar wrote: post #61
cjfd wrote: post #2

This talks about code complexity a lot. This, however, is not the chief source of complexity in many code bases. The number of tools needed to build things is the bane of the modern software developer. Also, the use of microservices where none are needed results in and enormous increase in complexity. Code complexity is relatively easy to fix compared to all of this.

I have seen a team be forced to use microservices for things still running on the same machine years later, with absolutely no benefit other than the powerpoint architecture slides looking fancier.

That may have well got them extra sales, which gave the team pay rises....
Post reply on HN