We did something similar with TypeScript strict mode
Turned it on per file with a ratchet count, and over a few months, the whole codebase was strict without ever blocking anyone
Ratchets in software development (2021)
21–30 of 43 posts
Re: Ratchets in software development (2021)
#22When the calls to THE FORBIDDEN METHOD are eventually replaced and the method removed, we can bury the ratchet.
Re: Ratchets in software development (2021)
#23I’ve never understood why linters don’t have this baked in. You want to deprecate a pattern, but marking it as an error and failing the build won’t work. So you mark it warning and fill everyone’s editors with yellow lines. And then we just get used to the noisy warnings. Ratchet is such a good word for it.
Python linters have a one-step way to suppress all individual errors. I assumed a SaaS like Sourcegraph is the only solution to ensure a codebase doesnt become worse.
Re: Ratchets in software development (2021)
#24[deleted]
Re: Ratchets in software development (2021)
#25Ratchet is a good name/pattern. It is also grandfathering. It is similar to how code coverage can be done. Old coverage may be low e.g. 40%, but may require 80% coverage on new lines, and over time coverage goes up. I wonder if there has ever been a sneaky situation where someone wanted to use forbiddenFunction() really bad, so they remove the call elsewhere and tidy that up, so they could start using it.
Yep. Grandfathering, deprecation. It's a new implementation of the same concepts.
And ditto for test coverage quality gates. I've seen that pattern used to get a frontend codebase from 5% coverage to >80%. It was just a cycle of Refactor -> Raise minimum coverage requirement -> Refactor again -> Ratchet again, with the coverage gate used to stop new work from bringing down the average.
Re: Ratchets in software development (2021)
#26I’ve never understood why linters don’t have this baked in. You want to deprecate a pattern, but marking it as an error and failing the build won’t work. So you mark it warning and fill everyone’s editors with yellow lines. And then we just get used to the noisy warnings. Ratchet is such a good word for it.
Grovel over your linter's command-line options and/or configuration file. It's not an uncommon feature but from my personal and limited experience it is also not always advertised as well as you like. For instance, golangci-lint has not just a feature to check only changed code, but several variants of it available, but I think possibly the only places that these are mentioned on its site are in the specific documentation of the issues configuration YAML documentation: https://golangci-lint.run/docs/configuration/file/#issues-co... written in a My Eyes Glaze Over coloration scheme [1], and mentioned in the last FAQ, which means reading to the bottom of that page to find out about it.
Most mature systems that can issue warnings about source code (linters, static analyzers, doc style enforcers, anything like that) have this feature somewhere because they all immediately encounter the problem that any new assertion about source code applied to code base even just two or three person-months large will immediately trigger vast swathes of code, and then immediately destroy their own market by being too scary to ever turn on. So it's a common problem with a fairly common solution. Just not always documented well.
[1]: Let me just grumble that in general coloration schemes should not try to "deprioritize" comments visually, but it is particularly a poor choice when the comments are the documentation in the most literal sense. I like my comment colors distinct, certainly, but not hidden.
Re: Ratchets in software development (2021)
#27I think this could be handled by an open rewrite rule [0], with the side effect that it could also fix it for you. [0]: https://docs.openrewrite.org/recipes
I forgot about this. It should be a great tool for agents. Does anyone have experience or tips to share? Moderne's thought of it too: https://www.moderne.ai/product/moddy
Re: Ratchets in software development (2021)
#28I know Jenkins is not fashionable these days, but the warnings-ng plugin is perfect for solving this in a tool-independent way. :chefskiss:
The way it works is - the underlying linter tool flags all the warnings, and the plugin helps you keep track of when any particular issue was introduced. You can add a quality gate to fail the build if any new issue was added in a merge request.
Re: Ratchets in software development (2021)
#29The general fault I see here, is that we don't typically make our work tracking tools so that they look at the code for us. Instead, our ticketing systems only have what we have put in them, directly.
This is obviously obnoxious when it comes to stuff like warnings and deprecations. But is also annoying when doing migrations of any kind. Or when working to raise test coverage. Anything that can be determined by checking the source code.
Re: Ratchets in software development (2021)
#30Interesting, props for coming up with a good name. But it's weird to me to call this a "ratchet", and not just a custom lint rule. Since it sounds exactly like a lint rule. The hard-coded count also sounds a bit like something that I would find annoying to maintain in the long run and it might be hard to get a feeling for whether or not the needle is moving in the right direction. - esp. when the count goes down and…
yeah that’s the way we do it at Notion. it’s important to store the allowed violation count in a file type that makes merges easy; we use TSV rather than JSON because dealing with commas and delimiters during merge conflict is super annoying and confusing. right now we have one huge ratchet.json.tsv file with all violations but it’s getting pretty ungainly now that it’s >1mb length.
interesting, so you guys call it a ratchet file? i thought it was something that OP came up with