3 ms·

> I think the value of metrics like this is limited, since code base size only very roughly corresponds to implementation complexity. This sounds a lot like t

by kqr 3y ago

> I think the value of metrics like this is limited, since code base size only very roughly corresponds to implementation complexity. This sounds a lot like the "your model is wrong because nuance X" argument. I want to remind you that all models are wrong, but some of them are useful anyway. In particular, I have found the size of source code to be a highly useful predictor of complexity. It has helped me predict where bugs are, where changes are made, where developers point out areas of large technical debt, and many other variables associated with complexity. The test of a model is not whether it accounts for all theoretical nuances, but rather whether it's empirically useful – and critically, has higher return-on-investment than alternative models. What model do you suggest for implementation complexity that you have verified to be better than code size? Genuinely interested! (Additionally, I have also successfully used the compressed size of input data to predict the resource requirements of processing that data, without actually having to process it first. This is useful because the compressed size can be approximated on-line rather cheaply.)

abtinf 3y ago
The GP’s point isn’t that the model is wrong “because nuance X”, it’s that the model directly contradicts good practice. You also changed the model under consideration (GP said compressed code size; you said just code size), disagreeing with a point the GP didn’t make.
- kqr 3y ago
  > The GP’s point isn’t that the model is wrong “because nuance X”, it’s that the model directly contradicts good practice. "Doesn't matter; had predictive value" is what comes to mind. "Good practise" isn't a defense against empirical evidence. That said, you're right that I missed the compressed part. I haven't tried compressing the source code before analysis, but I do suspect it would improve accuracy rather than decrease it. That's not a rigorous argument though, and I'm willing to accept that uncompressed code size might be a better model than compressed code size.

by kqr 3y ago

abtinf 3y ago

The GP’s point isn’t that the model is wrong “because nuance X”, it’s that the model directly contradicts good practice. You also changed the model under consideration (GP said compressed code size; you said just code size), disagreeing with a point the GP didn’t make.

kqr 3y ago
> The GP’s point isn’t that the model is wrong “because nuance X”, it’s that the model directly contradicts good practice. "Doesn't matter; had predictive value" is what comes to mind. "Good practise" isn't a defense against empirical evidence. That said, you're right that I missed the compressed part. I haven't tried compressing the source code before analysis, but I do suspect it would improve accuracy rather than decrease it. That's not a rigorous argument though, and I'm willing to accept that uncompressed code size might be a better model than compressed code size.