1. 58
  1.  

  2. 12

    I think I’d call this a “ratchet” if I wanted it to sound less naughty. :)

    Seems like a good idea to me.

    A related thing I’ve heard of a few times, which apparently has approximately never failed, is putting a deprecation banner and a sleep() call in your open source package’s install script when you want people to migrate away from it.

    1. 2

      +1 for rachet. I could never get away with having “shitlist” in my code at work.

    2. 12

      This was used extensively at GitHub, and it generally works very well. Decrementing the number as you refactor is also a nice little dopamine generator.

      1. 2

        Ever tempted to make a dashboard showing the number of entries in each ratchet list across the codebase? :)

      2. 5

        On related terms, I think helping people to push into the right direction is important. I have two examples to present:

        I added a version and a message parameter to the @deprecated annotation in Scala, such that every deprecation indicated the version they were introduced and a message indication why/what to use instead.¹ Then I added code to the compiler to categorize and order all deprecations and show them in a useful way during compilation.

        Back in that time Scala had a huge backlog of deprecations and generally no idea when or why things were deprecated. After adding versioning, it was finally possible to keep removals in sync with deprecations.

        Somewhere else I did the same with test-disabling annotations: Instead of people adding a blanket @Disabled, it’s now required to specify until when something is disabled (test will start failing afterward), who is responsible for it, an issue number and an explanation why the test was disabled.

        The number of forgotten disabled tests sank after that.


        ¹ This was undone recently, because the convenience to the author to save 5 seconds on deprecating something was deemed more important than the pain of users ending up with undocumented deprecations. Just shows what a lost cause this language really is. :-)

        1. 1

          We use this as well, and someone built a tracker called “albatross” to track migration progress visually. It works by grepping the codebase for a configured grep pattern every commit, and putting the result in a db. In theory, visual progress is nice to show off progress, especially to leadership looking to de-prioritize things..