3 ms·

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 o

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

by goto11 5y ago

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.