Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ratchets in software development (2021)

qntm.org

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Ratchets in software development (2021)

#31

Post by Normal_gaussian »

gorgoiler wrote: post #11

Love it! …but of course I’d worry about a diff that added one offense while removing another, leaving the net sum the same. Perhaps the author handles this? You want to alert on the former and praise on the latter, not have them cancel out through a simple sum. Admittedly it’s a rare sounding edge case. The more trad technique for this would be to mark the offending line with # noqa or # ignore: foo . Another way is…

This is exactly the issue I bumped into eight or so years ago. I had a ratchet style job that would maintain a file of all of the type issues in the system. Add one, remove one was very common - particularly when it amounted "transform one" so the error change is all on the same line. Note that this is compounded by the errors often showing up quite far away from the code change.

I ended up using something similar to `// @ts-ignore` which would encode a truncated hash of the error message on the line, as well as a truncated hash of the lines AST; the original error message and the justification.

These were long lines so were a PITA, but they immediately had this 'ratchet' effect.

I tried several times to move to a central file referencing the issues, but the complexity in maintaining the references with common refactors was a blocker.

Re: Ratchets in software development (2021)

#32

Post by nvader »

Although this isn't my own article, I wanted to share it because we refer to it often at Imbue because we have an internal system inspired by it. One remarkable side-effect I've discovered of a ratchet system is the increased code quality you get from agents, once you build your workflow to respect them.

I have no qualms about adding patterns like 'interior mutability' in Rust to a ratchet, and forbidding front-line coding agents from incrementing the counter. Then when a feature truly requires it, they can request their parent coordinator agent to bump the count, which gives it a chance to approve or deny the request.

This also gives us the ability to run clean-up agents on the codebase in the background. They are tasked with finding unreasonable instances of the failing ratchets (our ratchet tool spits out file and line numbers), and attempting to fix them.

An early iteration I was mostly amused (and slightly frustrated) to see a cleanup agent stuck in a loop as it tried to clean up `expect()` calls by converting them into `unwrap()`s, which were also forbidden. Then we would see the `unwrap()`s and attempt to fix them by converting them into `expect()`s.

Re: Ratchets in software development (2021)

#34

Post by MithrilTuxedo »

dominicrose wrote: post #33

> a script which runs at source code linting time There are moments when we don't bother with optional things like linting, formatting, warnings, etc. So it's important that there is a moment when these things aren't optional.

>So it's important that there is a moment when these things aren't optional.

I haven't found anything more effective than making sure it happens fast enough other devs don't have time to think about disabling it. They might make their changes locally relying on an IDE without running the full build, which pushes the exceptions to the build agent. Developers may not have privileges to modify those builds directly, but complaints and emergencies slowly erode impediments to deploying.

Re: Ratchets in software development (2021)

#35

Post by allannienhuis »

I did something like this years ago for a really large team (~50 devs) when first introducing linting into a legacy project. All we did was count the gross total number of errors for the lint run, and simply tracked it as a low-water mark - failing the build if the number was > the existing number of errors, and lowering the stored number if it was lower. So in practice people couldn't introduce new errors. The team was encouraged to use the boy-scout rule of fixing a few things anytime you had to touch a file for other reasons, but it wasn't a requirement. We threw up a simple line chart on a dashboard for visibility. It worked like a charm - total number went down to zero over the course of a year or so, without getting in the way of anyone trying to get new work done.

Re: Ratchets in software development (2021)

#36

Post by jayd16 »

burticlies wrote: post #4

I’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.

Honestly it would be better to bake in source control context so you can mark new code as more strict than legacy.

You can usually achieve this by adding ignore pragmas to your legacy warnings (although you need to touch that code). But at least that way, daily workflow will see errors and you can find the legacy errors by disabling the pragma.

Re: Ratchets in software development (2021)

#38

Post by loglog »

Counting warnings is a poor practice, because you don't see where warnings exist or are added or removed while reading or writing code. Suppression annotations in code next to where the problem occurs are more explicit, and the progress is easy to measure with e.g. git log -S. The main difficulty is automating adding these annotations. For at least one static analysis systems, there is an off the shelf solution: https://github.com/palantir/suppressible-error-prone

Re: Ratchets in software development (2021)

#39

Post by maxkfranz »

jitl wrote: post #16

I built a ratchet system for ESLint originally that we’ve extended it to work with TypeScript, Terraform, and Biome linters. integrating with each linger is complex but it pays dividends - it’s so handy to be able to write a new lint rule or introduce an off-the-shelf rule without needing to fix all existing violations. We maintain allowed error counts on a file-by-file basis which makes it easier for developers to u…

This is a really pragmatic approach.

Your errors-over-time chart feels pretty accurate to me. The yellow warnings line really sneaks up on you over time.

Re: Ratchets in software development (2021)

#40

Post by NortySpock »

allannienhuis wrote: post #35

I did something like this years ago for a really large team (~50 devs) when first introducing linting into a legacy project. All we did was count the gross total number of errors for the lint run, and simply tracked it as a low-water mark - failing the build if the number was > the existing number of errors, and lowering the stored number if it was lower. So in practice people couldn't introduce new errors. The team…

How do you add new linter rules? Do you have to clean up an equivalent number of lines of warnings to enable an additional linter rule?
Post reply on HN