←back to thread

-2000 Lines of code (2004)

(www.folklore.org)
519 points xeonmc | 1 comments | 25 Jun 25 19:53 UTC | HN request time: 0.212s | source
Show context
jfengel ◴[25 Jun 25 21:46 UTC] No.44382104[source]▶
In college I worked for a company whose goal was to prove that their management techniques could get a bunch of freshman to write quality code.

They couldn't. I would go find the code that caused a bug, fix it and discover that the bug was still there. Because previous students had, rather than add a parameter to a function, would make a copy and slightly modify it.

I deleted about 3/4 of their code base (thousands of lines of Turbo Pascal) that fall.

Bonus: the customer was the Department of Energy, and the program managed nuclear material inventory. Sleep tight.

replies(7): >>44382155 #>>44382420 #>>44382634 #>>44382701 #>>44383041 #>>44385840 #>>44390812 #
al_borland ◴[26 Jun 25 00:16 UTC] No.44383041[source]▶
I work with someone who has a habit of code duplication like this. Typically it’s an effort to turn around something quickly for someone who is demanding and loud. Refactoring the shared function to support the end edge case would take more time and testing, so he doesn’t do it. This is a symptom of the core problem.
replies(3): >>44384293 #>>44386685 #>>44390754 #
1. akdor1154 ◴[26 Jun 25 20:03 UTC] No.44390754[source]▶
I have a habit of doing this for data processing code (python, polars).

For other code it's an absolute stink and i agree. But for data transforms... I've seen the alternative, a neatly abstracted in-house library of abstracted combinations of dataframe operations with different parameters and.. It's the most aesthetically pleasing unfathomable hell I've ever experienced.

So now, when munging dataframes, i will be much faster to reach for 'copy that function and modify it slightly' - maintenance headache, but at least the result is readable.