4 ms·

There is no way to measure code quality While it's indeed hard to get objective measurements looking at the codebase alone, telling a manager things like "loo

by stinos 5y ago

There is no way to measure code quality While it's indeed hard to get objective measurements looking at the codebase alone, telling a manager things like "look, this is going to take 5x the amount of time it should because the current code is a complete mess so I have to be extra careful not to break things and it takes way longer than it should to figure out where I have to put the new feature in order to mimimize the amount of extra chaos created" or "I cannot do anything sensibly without refactoring this first but it will pay off in the next couple of months and years to follow" should make it pretty clear the quality isn't where it should be. If management doesn't grasp that, or doesn't want to hear it, then management quality is probably at the same level as the code's. I know I'm in a position not every developer is, but when needed I ask and get extra time for things like this. Because I've seen what happens when you try to build a trainwreck on top of existing ones: that stuff is exponential, at least.

goto11 5y ago
Sure you can say such things. My point is just there is no way to determine if you are right. Unless you make an A/B test where you both refactor and keep the old version around, and measure how much time it takes for the same developers to implement same change on both code bases. But nobody ever does such a test since it would be prohibitively expensive.
- deleted 5y ago
  [deleted]
- ken47 5y ago
  The example assertions he was making were non falsifiable. However, if the claims were slightly tweaked to say something along the lines of: "historically, a code modification like the one you've requested has taken 5n units of time. After refactoring, such a change will take n units of time." You wouldn't perform an A/B test to prove your claim. The managers would simply have to trust you for the reputable engineer that you are, and hopefully observe substantially increased velocity after the refactoring.
  - goto11 5y ago
    > The managers would simply have to trust you Yeah, that is my point. You can make up any bullshit number, and there is no way to prove of disprove it.
- stinos 5y ago
  My point is just there is no way to determine if you are right. That is a fair, so I guess that is the point where trust in experience kicks in, like the sibling comment mentions already. But nobody ever does such a test since it would be prohibitively expensive.* And also rather hard to do. You cannot reliably use the same developers to do it because both tests would influence each other. Using different developers would raise questions about whether both are at the same level. Etc. Yet I do think some aspects might be easier to prove than other. Has perhaps been done already but say you take a bit of code with formatting completely off and inconsistent, and the same piece where it looks uniform. Have people read it a couple of times, then ask questions about it. Or something like that, I'm not into that research but you get the point: should be doable to objectively measure which one has the least cognitive overhead and gets understood the fastest. Assuming it's the uniform one, that would then open the door to saying it's worth spending time now to apply project-wide formatting vs continuing with a mix of styles as-is.
Verdex 5y ago
I think this is sort of right ... but: "Hey boss ... this code the other vendor handed off to us is really bad code quality. We'll need to rewrite it or it's going to take 10x as long to do the feature than what we initially estimated." "Hm, that's not good. I'll talk to the customer." <later> "So that's how long it will take without a rewrite." "That doesn't sound right. I'll ask the other vendor how long it will take them to implement the feature." <later> "The other vendor did it in two days. Your team is fired." <later> "We've got another round of bug reports from the field. Also a class action law suit from angry customers. Also the product killed someone." "Someone died? It's a website how is that even possible?" "One of the many bugs causes the screen to flash wildly. Someone viewed it who was sensitive to flashing lights and had a violent seizure that ultimately claimed their life." ----- Without a separate objective code quality metric, you can't determine between two parties who argue about what the code quality is. It could be someone isn't willing to spend some time learning something new. It could be that someone is just unfamiliar with the code. It could be that someone is cutting corners and writing dangerous code. All you can do is to pick the people with the best track record and hope that you don't find out you choose wrong after spending millions of dollars and burning a lot of customer good will. Because of this, it would be really nice if we had a different way to measure code quality besides: "The software developers are complaining about it."
marcus_holmes 5y ago
yeah but Not Invented Here is also a thing. Experienced devs also have Their Way Of Doing Things and if the code doesn't fit that, then it's "garbage" and needs to be refactored. I've seen at least two perfectly good code bases get refactored badly because the dev didn't understand how they worked, or they were in a language the dev didn't want to work in [0]. [0] One of them was me, and in my defence it was PHP.

by stinos 5y ago

goto11 5y ago

Sure you can say such things. My point is just there is no way to determine if you are right. Unless you make an A/B test where you both refactor and keep the old version around, and measure how much time it takes for the same developers to implement same change on both code bases. But nobody ever does such a test since it would be prohibitively expensive.

deleted 5y ago
[deleted]
ken47 5y ago
The example assertions he was making were non falsifiable. However, if the claims were slightly tweaked to say something along the lines of: "historically, a code modification like the one you've requested has taken 5n units of time. After refactoring, such a change will take n units of time." You wouldn't perform an A/B test to prove your claim. The managers would simply have to trust you for the reputable engineer that you are, and hopefully observe substantially increased velocity after the refactoring.
- goto11 5y ago
  > The managers would simply have to trust you Yeah, that is my point. You can make up any bullshit number, and there is no way to prove of disprove it.
stinos 5y ago
My point is just there is no way to determine if you are right. That is a fair, so I guess that is the point where trust in experience kicks in, like the sibling comment mentions already. But nobody ever does such a test since it would be prohibitively expensive.* And also rather hard to do. You cannot reliably use the same developers to do it because both tests would influence each other. Using different developers would raise questions about whether both are at the same level. Etc. Yet I do think some aspects might be easier to prove than other. Has perhaps been done already but say you take a bit of code with formatting completely off and inconsistent, and the same piece where it looks uniform. Have people read it a couple of times, then ask questions about it. Or something like that, I'm not into that research but you get the point: should be doable to objectively measure which one has the least cognitive overhead and gets understood the fastest. Assuming it's the uniform one, that would then open the door to saying it's worth spending time now to apply project-wide formatting vs continuing with a mix of styles as-is.

Verdex 5y ago

I think this is sort of right ... but: "Hey boss ... this code the other vendor handed off to us is really bad code quality. We'll need to rewrite it or it's going to take 10x as long to do the feature than what we initially estimated." "Hm, that's not good. I'll talk to the customer." <later> "So that's how long it will take without a rewrite." "That doesn't sound right. I'll ask the other vendor how long it will take them to implement the feature." <later> "The other vendor did it in two days. Your team is fired." <later> "We've got another round of bug reports from the field. Also a class action law suit from angry customers. Also the product killed someone." "Someone died? It's a website how is that even possible?" "One of the many bugs causes the screen to flash wildly. Someone viewed it who was sensitive to flashing lights and had a violent seizure that ultimately claimed their life." ----- Without a separate objective code quality metric, you can't determine between two parties who argue about what the code quality is. It could be someone isn't willing to spend some time learning something new. It could be that someone is just unfamiliar with the code. It could be that someone is cutting corners and writing dangerous code. All you can do is to pick the people with the best track record and hope that you don't find out you choose wrong after spending millions of dollars and burning a lot of customer good will. Because of this, it would be really nice if we had a different way to measure code quality besides: "The software developers are complaining about it."

marcus_holmes 5y ago

yeah but Not Invented Here is also a thing. Experienced devs also have Their Way Of Doing Things and if the code doesn't fit that, then it's "garbage" and needs to be refactored. I've seen at least two perfectly good code bases get refactored badly because the dev didn't understand how they worked, or they were in a language the dev didn't want to work in [0]. [0] One of them was me, and in my defence it was PHP.