3 ms·

Yeah, a large problem in software engineering is that we have zero metrics for how terrible anything is. So, you have some engineers complaining about code wri

by Verdex 5y ago

Yeah, a large problem in software engineering is that we have zero metrics for how terrible anything is. So, you have some engineers complaining about code written by another one of your vendors. Are they just unfamiliar with the technique/programming language being used? Or maybe the other vender is just too sophisticated and their engineers can just do better? Or maybe they were a bunch of hacks that threw together code until it worked well enough to pass the acceptance criteria needed to get the final milestone payment released. One way to pass the buck is to just "hire on the ability to get shit done" and justify it with "well, the shit needed to be done and now it is." I can see it working okayish in the short term. However, eventually you want something (or need something a competitor has) and the answer is "cannot be done because the codebase is infested with demon spiders." Meanwhile the "got shit done" people are either gone (if you're lucky) or insist that the only way to do it is to continue the nightmare development philosophy they created on their own that mixes ideas from shintoism and kabbalah into C++ templates. Every week they're "making good progress" but the features are going to show up exactly never.

zebraflask 5y ago
You know, I recognize that this is a somewhat serious discussion? But I can think of a few scenarios from experience where saying "the codebase is infested with demon spiders, can't do it" would be a satisfying thing to say in reply to unrealistic development requirements.
taylodl 5y ago
> "we have zero metrics for how terrible anything is" There's Cyclomatic Complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity) but I think that's too low-level for what we really need. Cyclomatic Complexity allows us to evaluate one function implementation versus another, when what we really want is the ability to evaluate different architectures and designs.
- Verdex 5y ago
  Yes, we do have Cyclomatic Complexity and it seems like that's it. Unfortunately, Cyclomatic Complexity is of dubious value. Even the wiki link you have here contains a section where they question the correlation between CC and the number of defects. Some studies say yes, but it looks like total program length is also correlated and sometimes better. Or in other words, line count might be a better metric than CC, which isn't exactly a ringing endorsement. Additionally, even if CC turns out to be useful, it is rather targeted. Basically, it's a metric to make sure you don't have too many if-statements[1]. Not as effective in our current OO/FP world where lots of decisions can be shunted off to an unknown object or lambda. However, whether or not you want to claim CC is useful for non-if-statement branches, it definitely doesn't say anything about code that's bad because of bad variable names, or code that's bad because of deep inheritance, or code that's bad because the wrong abstraction is used, etc (which is kind of what you're already saying with your statement about architectures and designs). [1] - So, I guess you could probably create a CC setup that is able to count linear independent paths that aren't if-statement related. However, both OO and FP allow you to setup scenarios where the execution path indirection is decided at run time (pass in a different object implementation or a different lambda). So you crash head first into the halting problem pretty quickly. [Not to mention, I've never seen anyone try to do this ... although I haven't actually been checking very carefully, so maybe there are tools that try to do this in a limited fashion?] However, it's also debatable which linearly independent paths are bad and which ones are actually helpful. Like, I bet that TCP library call contains a ton of linear independent paths. But if you fix that by just vomiting your hand rolled communication protocol onto the internet with objectively less linear independent paths, then I can't call that an improvement in program comprehensibility just because the linear independent paths have been reduced.

by Verdex 5y ago

zebraflask 5y ago

You know, I recognize that this is a somewhat serious discussion? But I can think of a few scenarios from experience where saying "the codebase is infested with demon spiders, can't do it" would be a satisfying thing to say in reply to unrealistic development requirements.

taylodl 5y ago

> "we have zero metrics for how terrible anything is" There's Cyclomatic Complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity) but I think that's too low-level for what we really need. Cyclomatic Complexity allows us to evaluate one function implementation versus another, when what we really want is the ability to evaluate different architectures and designs.

Verdex 5y ago
Yes, we do have Cyclomatic Complexity and it seems like that's it. Unfortunately, Cyclomatic Complexity is of dubious value. Even the wiki link you have here contains a section where they question the correlation between CC and the number of defects. Some studies say yes, but it looks like total program length is also correlated and sometimes better. Or in other words, line count might be a better metric than CC, which isn't exactly a ringing endorsement. Additionally, even if CC turns out to be useful, it is rather targeted. Basically, it's a metric to make sure you don't have too many if-statements[1]. Not as effective in our current OO/FP world where lots of decisions can be shunted off to an unknown object or lambda. However, whether or not you want to claim CC is useful for non-if-statement branches, it definitely doesn't say anything about code that's bad because of bad variable names, or code that's bad because of deep inheritance, or code that's bad because the wrong abstraction is used, etc (which is kind of what you're already saying with your statement about architectures and designs). [1] - So, I guess you could probably create a CC setup that is able to count linear independent paths that aren't if-statement related. However, both OO and FP allow you to setup scenarios where the execution path indirection is decided at run time (pass in a different object implementation or a different lambda). So you crash head first into the halting problem pretty quickly. [Not to mention, I've never seen anyone try to do this ... although I haven't actually been checking very carefully, so maybe there are tools that try to do this in a limited fashion?] However, it's also debatable which linearly independent paths are bad and which ones are actually helpful. Like, I bet that TCP library call contains a ton of linear independent paths. But if you fix that by just vomiting your hand rolled communication protocol onto the internet with objectively less linear independent paths, then I can't call that an improvement in program comprehensibility just because the linear independent paths have been reduced.