1. 9

  2. 12

    This article is good, but I feel as if it’s conflating a few different things, and I think that obscures what it’s actually getting at.

    I could gloss and just say that I’m firmly in the, “if it works, don’t fix it” camp. But that’d miss the point.

    What this article is dancing around is that there are at least three different ways to define “it works”: does it work for the customer, in terms of doing what they need correctly and reliably; does it work for the organization, in terms of doing things with minimal ongoing investment; and does it work for the developers, in terms of being appropriately clean for the amount of maintenance done on the project.

    You can’t really talk about “works” outside of acknowledging these three audiences, and their different needs. You can improve organizational reliability while making developer maintenance a nightmare (I’d argue that adopting NoSQLs can frequently end up in this boat). You can improve the developer experience while making it hell on the customer (a very-readable refactoring might make things slow, and exposing all the configuration nobs to the customer lets you claim it’s there fault when things don’t work right). And you can improve the customer experience while wreaking hell on the organization (just have a human go through and fix the 20% errors that slip through the processor). In all these situations, at least two audiences might not even feel there’s something to fix, and fixing it for that audience may involve trade-offs with the others. And these are all real things I’ve seen.

    I’ve worked as a manager, a dev, and an in-function-but-not-in-name PM, and here’s my version of what I feel like this article is trying to get at: if a piece of software is reliable and no one needs to do much with it except once in a blue moon, then no, for the love of heaven, leave it be. I don’t care if it’s written in QBasic and running in DOSBox on a Mac mini in the server closet with Technic™ blocks shimming the thing into a 1U enclosure: if a dev needs to go in there once a year at most, it works, do not touch.

    But if we frequently need to go into the code base, even if it does work but needs frequent upkeep (e.g., to cite a real example, maybe certain servers or processes are hard-coded in some way, so adding new ones requires deploying a new version of the app), it may be entirely reasonable to spend time refactoring and improving something that works. You just need to balance all the various risks involved and decide it’s worth proceeding.

    1. 2

      Well said!

    2. 2

      Find the code parts that you work actively on the most and fix these parts to make them more understandable and readable.

      Where are all these teams that have extra time to go in and just “fix up” code? If I went into code without a purpose other than “fix it up” I’d probably get my kneecaps broken for not working on stuff we actually need to do.

      If you go into a code jungle to fix or add something, you’re expected to document the important stuff and fix up the parts you’re working on while you’re there. Leave it better than you found it for the next poor soul going back into that part of the jungle. If you’re in there to fix something, make a map to tell other people how to get there and then fix it–don’t spend another week or two to drain the swamp, kill all the alligators, and landscape the whole place.

      1. 2

        I assume this article is addressing a certain type of programmer that simply needs to fix all the broken things they hit. That type is extremely common. You’re correctly pointing out why that’s a problem.

        1. 3

          The article distinguishes between those “It works, don’t fix it” and “It’s not the way I would write it, I must ‘fix’ it”, and then introduces “core parts” should be cleaned up (which I quoted). My point is the cleaning code up is something you do as you work on it, not a separate dedicated activity.