Most active commenters

    ←back to thread

    -2000 Lines of code

    (www.folklore.org)
    502 points xeonmc | 12 comments | 25 Jun 25 19:53 UTC | HN request time: 0.637s | source | bottom
    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 #
    1. uticus ◴[25 Jun 25 21:55 UTC] No.44382155[source]▶
    > make a copy and slightly modify it

    In addition to not breaking existing code, also has added benefit of boosting personal contribution metrics in eyes of management. Oh and it's really easy to revert things - all I have to do is find the latest copy and delete it. It'll work great, promise.

    replies(2): >>44382661 #>>44383681 #
    2. 0cf8612b2e1e ◴[25 Jun 25 23:12 UTC] No.44382661[source]▶
    I mean…when you have a pile of spaghetti, there is only so much you can do.
    replies(3): >>44382790 #>>44385636 #>>44386821 #
    3. travisgriggs ◴[25 Jun 25 23:33 UTC] No.44382790[source]▶
    Ask for more staff, reorganize the team into a set of multiple teams, and hire more middle management! Win win for the manager.
    replies(1): >>44384296 #
    4. nico ◴[26 Jun 25 02:21 UTC] No.44383681[source]▶
    Immutable functions! I guess that’s one way of doing functional programming /s
    replies(2): >>44385324 #>>44385971 #
    5. 8n4vidtmkvmk ◴[26 Jun 25 04:57 UTC] No.44384296{3}[source]▶
    Add tests to the function as it exists today. Submit. Add new functionality, make sure tests still pass. Done. Updating a function here and there shouldn't require more staff.
    replies(1): >>44386844 #
    6. Sharlin ◴[26 Jun 25 08:20 UTC] No.44385324[source]▶
    In a (very real) sense, git is an immutable data structure of immutable snapshots of code.
    replies(1): >>44388947 #
    7. mrweasel ◴[26 Jun 25 09:24 UTC] No.44385636[source]▶
    Spaghetti piles are where you can do the most... if you're brave enough and have agency to do so.
    8. windward ◴[26 Jun 25 10:27 UTC] No.44385971[source]▶
    pfft, that's just symbol versioning
    9. sumtechguy ◴[26 Jun 25 12:36 UTC] No.44386821[source]▶
    Add some meat sauce and more spaghetti :)
    10. SkyBelow ◴[26 Jun 25 12:39 UTC] No.44386844{4}[source]▶
    This implies adding tests that accurately capture all the nuances of the function and don't test the simplest logic need to hit code coverage. When we are talking someone new to the function, then this is about the same as asking them to learn the function so they can be sure they didn't make an error when they changed it. The benefit of tests is that they are written by the person creating the function originally who is most aware of the hidden dangers of it.

    I'm distrustful on unit testing as I've seen too many tests written to make code coverage numbers but that don't actually test the functions they are aimed at. A non-trivial number which run the function asynchronously and then report a successful run before the function even finishes executing, meaning that even throwing errors don't fail the tests (granted, part of that is on the testing framework for letting unexpected errors ever result in a pass).

    replies(1): >>44390354 #
    11. ThunderSizzle ◴[26 Jun 25 16:32 UTC] No.44388947{3}[source]▶
    You can do commit squashing in git, right? I know HG history editing wa much more of a pain than it seems to be in git.
    12. dml2135 ◴[26 Jun 25 19:09 UTC] No.44390354{5}[source]▶
    Of course, this is the way you need to write tests -- to test the actual logical pathways and requirements of the code, and not just finagle them together to overfit some code coverage metric.