4 ms·
All the time! Two weeks ago I found something in a critical library at work (that ~every single C++ binary we run depends on: our main implementation of our cu
by afc 7y ago
All the time!
Two weeks ago I found something in a critical library at work (that ~every single C++ binary we run depends on: our main implementation of our custom threads' executor API) that made no sense. I couldn't understand why a variable was being rounded before being passed down to a lower layer, in a way that introduced an average 0.5 Ms of latency to many operations (I estimate that at peak, just one of the binaries that I maintain, a caching system, runs this code at least 200 million times per second), for no gain that I could see. There even was a comment attempting to explain why the rounding logic was added, but it was factually incorrect. As far as I could tell, I could just delete the rounding logic and everything would just work. I was baffled.
... until I looked at the code history! It explained it immediately (well, in like 5 to 10 minutes): the code from 2013, when the rounding was introduced, was calling into some lower level API that received parameters in a way that had limitations that ... Well, let's just say made it very clear to me why the rounding had been added.
Someone cleaned up the lower level library in 2016 or so, but the rounding remained in the upper layer.
This is just one example of many. I do this all the time.
Just two days ago, I was running scripts to extract lines-of-code by author and reviewer over different directories to get a sense of the size of the contributions of different team members, as part of the employee performance evaluation process (obviously, LOC is just one of many many many signals, and has to be taken in context). "Interesting, this person has already contributed 4k LOC to this particular directory, I didn't realize that!" Or "Source code files in the directories of the components that this person is a Tech Lead for had contributions from 131 engineers in 2019; of these, at least 56 engineers contributed more than 100 loc."
I guess I'll call out also that when I find a reproduceable bug that I can't explain, being able to binary search in the code history until I find the first change that exhibits the bug can be a life saver. I don't do this very often, but I estimate that, when I've done it, it has saved me days, possibly even weeks, of work.
- sneak 7y agoSeconded heartily: git bisect is one of those tools I use very infrequently but when I do, it is a lifesaver.
- ulrikrasmussen 7y agoYour first example hits the nail on its head. I use code history all the time to understand the context in which a bug or weird looking piece of code was introduced. If the developer who wrote it isn't around anymore, or can't remember the details, then this information is really crucial to gain confidence that changing or removing the code won't just introduce another obscure bug because you didn't understand the reasoning behind it.
- manaskarekar 7y agoChestertons Fence, to put a name to the phenomenon. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
- thewebcount 7y agoHow so? In GP's case, they found that the "fence" really was no longer needed: > Someone cleaned up the lower level library in 2016 or so, but the rounding remained in the upper layer. This is like the opposite of a Chesterton fence, where the reason it was put up no longer exists, so it's totally safe to remove it.
- 0xcde4c3db 7y agoThe point of Chesterton's fence isn't that the fence is necessarily still useful, it's that being ignorant of the usefulness of a thing isn't equivalent to knowing that it's useless.
- jdminhbg 7y ago> Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it. This is the bit that applies.
- reificator 7y agoChesterton's fence is not about never changing things. They followed Chesterton's fence to the letter. They saw something that didn't make sense, and then tracked down why it worked the way it did. Once they understood the root cause, they examined the environment and discovered that the underlying issue had been fixed. That allowed them to confidently rework the inconvenient behavior into something better.