3 ms·
The most useful metric in my view, and one I learned at IBM, is fixes applied over shipped lines of code. Multiple fixes over the same lines of code is exponent
by dtagames 4y ago
The most useful metric in my view, and one I learned at IBM, is fixes applied over shipped lines of code. Multiple fixes over the same lines of code is exponentially bad.
IBM started measuring code defects vs working code in this way because productivity studies they did showed that fixes took much more time per LOC than new code and had other costs (customer sat, doc changes, reputation) besides.
- wahnfrieden 4y agoThis is a variant of DORA’s change failure rate
- renewiltord 4y agoBut ultimately, the outcome is that IBM is a dinosaur corp and no one looks to them for technical leadership of any sort. They don't deliver and they're not well known for writing particularly good code. So that calls the value of the metric into question.
- prepend 4y agoThis seems easily gamed by just producing lots of lines of code. Adding inline documentation would improve this metric. This does explain some absolute dogshit products IBM made as maybe they were optimizing for this metric by having 1000 lines when one would do. I’m bitter from having to decompile and debug websphere in the 90s and 00s. I think this runs into a problem is that programmers are good at minmaxing. So any rote metrics will end up being gamed pretty quickly.
- dtagames 4y agoEverything was peer reviewed, so no extra code. Also, every single line had a comment, so no padding with comments. On the "why they failed" aspect, 100 years is a pretty good run. There are lots of reasons IBM is less relevant today, but buggy software isn't one of them.
- prepend 4y agoI’m sure it’s buggy software didn’t help and I think it contributed to IBM’s reputation for poor software.