3 ms·
Joel Spolsky, just about 22 years ago: Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little ha
by a4isms 5y ago
Joel Spolsky, just about 22 years ago:
Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Yes, it may be the case that we no longer support Internet Explorer, and none of our customers even know that Windows 95 ever existed, much less run it. And our users look at a floopy disk and exclaim "Cool, a 3D-printed save icon!"
So yes, lots of code serves "no good purpose" today, even if it was a good purpose when it was written. HARD AGREE.
Presumably written to amuse the author? Hard disagree from my n=1 experience, even if that experience with commercial software development dates back to the early 1980s. I think those cases are outliers that exist, but shouldn't drive our decision-making. The key word is "presumably." Presuming that code we find doesn't seem to serve a purpose was written for the self-gratification of the author is, in my experience, a very bad way to manage risk.
I'm prepared to assume that code which doesn't seem to serve a purpose may no longer serve a purpose, but while it may never have served a purpose, I'll try my best to find out what that purpose was before throwing it away.
- emodendroket 5y agoI could maybe buy that if the code was very old. When it’s a couple months old I find it hard to swallow.
- a4isms 5y agoIf the code is only a couple of months old, why presume anything when the original authors are probably still around? When the pull requests are right there to look at? When the JIRA tickets either completely explain, or link to documents that explain the acceptance criteria for the code? When a quick search can pull up slack conversations about the code? Going back to the metaphor, if the fence you want to pull down is only a couple of months old, the knowledge of why it was put up in the first place is readily available. Just ask around.
- emodendroket 5y agoSometimes they’re not around anymore regardless. Sometimes I’ll ask and become more secure in my conviction that it is an exercise in self gratification. From these experiences I can extrapolate to the general case and say “there’s always a sensible reason” is hogwash.