The reverts will continue until morale improves

Posted by hans_castorp 2 days ago

Counter235Comment48OpenOriginal

Comments

Comment by sammatilda 2 days ago

Better to revert than lose a community that is invested in your ecosystem that starts looking elsewhere. I congratulate the team in acknowledging and doing the right thing. As a developer myself, I know it is a painful thing to do but important to listen to the community.

Comment by lubujackson 2 days ago

As an engineer, this revert post is such a positive signal of appropriate stewardship. Devs know how painful it is to build and refine something only for it to be flushed.

Congrats on the team for putting stability ahead of features for such an important codebase.

Comment by flossly 2 days ago

I think maintainers here listened to their gut feeling and trusted their experience.

On top of that I think this is actually great FLOSS news, knowing how many commercial products have sacrificed proper professional programming on the altar of shareholder expectations.

Comment by jeremyjh 2 days ago

Agreed. People using Postgres aren’t there for the next feature release. We want to see development continue but not at the expense of stability. This is a very mature team and I’m glad they shared this.

Comment by moomin 2 days ago

I’ve experienced this myself. I’ve had to downgrade my opinion of my own code. LLMs are great at pointing out the edge cases that you might have taken years to find. Honestly feels quite dispiriting but we move on.

Comment by crazygringo 2 days ago

Same here. It's been a real eye-opener.

Previously my main concern was with LLM's writing worse code. Now my concern is the ability to write better code than I was ever able to write before -- considering every possible potential bug and race condition and error state and what have you -- but at what cost? How much more time do you have to spend researching, designing, making decisions around every possible edge case and state?

Before, you couldn't even attempt to balance quality with speed, because you couldn't see the quality in advance. You had to wait for bug reports to come in. Now, you're confronting quality up-front in a much deeper way. Which allows for much more reliable software, but then you have to decide how much effort is worth it and how much isn't?

Comment by bunderbunder 2 days ago

This keeps bringing me back to John Backus’s Turing award lecture/paper, “Can Programming be Liberated from the Von Neumann Style?”

In it he pointed out a huge deficiency of most programming languages that still haunts us: they’re wickedly difficult to reason about. So proving important properties about programs is all but infeasible.

So we try to handle it empirically with unit tests, but that has its limitations.

LLMs can kinda sorta do it analytically, but that isn’t completely satisfying, either. The results are probabilistic, and they are pretty bad at inferring intent which can be a source of both type I and type II errors. But still, it would be silly to throw out a layer of Swiss cheese for having holes.

But I sure do wish we could have a plausible version of Backus’s original vision of a language that lets us formally declare (a useful subset of) the specification and then statically verify that the program conforms to it.

Comment by tygon 2 days ago

Just need to create systems to assign priority to issues. And then systems for those systems. And...

Comment by thin_carapace 2 days ago

> every possible bug and race condition and error state

a particular statement to make during the slop apocalypse

Comment by crazygringo 2 days ago

I mean, it depends on how you use an LLM like Claude.

You can not know what you're doing and use it to write slop.

Or you can set up your project with best practices in every way with full design documents and code that flows from design and full rigor around everything.

I do it the second way. And so yes, I find myself being confronted with so many edge cases that I just never thought about before. And I'd say it about doubles the time it takes me to deliver stuff, and I'm not always sure it's worth it.

Comment by thin_carapace 2 days ago

I don't intend to argue that your experience is invalid. if 99% of people don't use ai in your way then you must understand your argument is parallel to that of gun control. anyway the edge cases you are unexpectedly encountering through ai, may I ask on average how many of them would be career ruining (or life endangering) as a percentage?

Comment by crazygringo 1 day ago

99% of people? Gun control? Career ruining? Life endangering?

You speak in hyperbolics, my friend. You may be lacking some realistic perspective here.

Plenty of people who are using LLM's within technical organizations, as opposed to script kiddies vibe coding, are encountering the same kind of issue. And people spend lots of time fixing bugs in existing code anyways. This is just a simple question of newly-visible tradeoffs.

Comment by thin_carapace 18 hours ago

your account has been here since 2011. unless the account got sold off, i take it that you're my elder and therefore are deserving of respect. so respectfully I ask, if you made a comment opening multiple avenues of discussion, and somebody shut them all down without acknowledgement, how you would react personally?

Comment by 18 hours ago

Comment by JeremyNT 2 days ago

Most of my old defects fall into tradeoffs I knowingly made at the time: well, this edge case is really unlikely, not worth pursuing a fix, the remediation won't be bad, some jank isn't going to annoy users too much, etc. But LLMs don't care: a bug is a bug, and they'll happily surface it for you.

Being able to take an old code base up to 100% test coverage alone is incredibly eye opening.

Comment by karmakaze 2 days ago

> I have been on the receiving end of some of that

Multiple features?

> Maybe we just didn’t do a good enough job. Maybe the code was just not good enough. We’ll learn and improve. It’s probably some of that, and I’m mentioning it here to not give the impression that it was only the other factors that I’m going to mention.

> It could also be a coincidence. Maybe we had been on such a good roll that we attempted to tackle several features that turned out to be too hard, or at least too hard to finish in time.

All of the above seem clearly the case--not that it could be realized at the time of cutoff and not getting it cleaned up in the window.

> we, meaning all the developers affected, have had enough time to fully reflect on all this.

Title should be: The reverts will continue until quality improves. Humour is good for the clicks but also a means of deflection. I sort of feel bad saying without putting in effort contributing myself but having it merged would have been worse.

Comment by AmazingEveryDay 2 days ago

I clicked it expecting talk of llm/ai stuff but it took several paragraphs for author to get there, and to get to the point.

Not quite as bad as those recipe sites that expect you to read the rando's life story before the recipe, though.

Comment by eclipticplane 2 days ago

We can thank Google for that.

Comment by stevekemp 2 days ago

Copyright law; you can't copyright a recipe.

The "life story" is a means to it easier to issue takedown notices, and report rehosters for copyright infringement.

Google isn't involved.

Comment by fancy_pantser 2 days ago

I got so sick of those recipe stories that I made a free browser extension that looks for and surfaces recipes straight to the top in a modal: https://github.com/sean-public/RecipeFilter

Comment by swiftcoder 2 days ago

Reverts kind of suck when it's your feature getting reverted, no doubt. But for something as foundational as Postgres, the more reverts the better...

Comment by glouwbug 2 days ago

[flagged]

Comment by Paracompact 2 days ago

The blog post mentions rising standards of quality enabled by AI-assisted code review, and that reverted code predates the era of AI. Even very competently managed codebases are not above mistakes, especially when held to as high of a standard as this.

Comment by Gigachad 2 days ago

I’ve noticed the GitHub copilot reviews have gone from mostly nitpicks to very complicated issues that are hard to even understand or validate. Some of these are incorrect but some of them are actual findings of issues that simply would have gone unaddressed previously.

So a lot of this increase in bug reports lately is simply that we are more able to find issues which would previously have been shipped and probably wouldn’t have even been noticed by users for a long time. The minimum bar for software quality is going up, there's no excuse to ship software which contains bugs that could be detected by an LLM.

Comment by jvanderbot 2 days ago

Well I have a document for you to read on this very question!

Comment by glouwbug 2 days ago

[flagged]

Comment by kbenson 2 days ago

GP is referring to the submission, in case that wasn't obvious. It's opining as to possible reasons, given the author is one of the people who had a feature reverted.

> Did someone not understand what went in?

Unlikely, from the context.

> Might someone have offloaded their thinking to some external tool?

No, according to the author, since the features predate most current LLM assisted coding.

> Did people stop caring?

I'm not sure what this means. Presumably things were reverted because people cared enough to make sure it was good quality before being released.

> Did someone not plan or design a feature in full?

An admitted possibility

> Were the timelines unrealistic?

Depending on what you mean, that may be correct according to the article, but I suspect not in the way you mean.

> Maybe with so many reverts timelines should be revised?

It sounds like there was a very large increase in load in some of the people that would commonly review during this time period, and that may or may not continue to happen to a greater or lesser degree in the future, it depends on how LLMs advance in finding bugs and if there are other large waved of bugs reported.

Comment by cwillu 2 days ago

Huh?

Comment by stickfigure 2 days ago

Take any codebase you built in the pre-AI era and run it through AI review. I guarantee, no matter how smart you are or how diligently you write tests, you will be absolutely gobsmacked by the findings. Turns out we haven't been writing perfect software all this time and we have some catching up to do.

Comment by Rapzid 2 days ago

For those not familiar with the attention economy; the headline is clickbate and not indicative of the articles point.

Comment by happyPersonR 1 day ago

A lot of people in opensource projects put their heads in the sand, and didn’t want to deal with all of the stuff coming out of LLM assisted code. This is a much better idea. We were always short of hands to help build things … and shorter still of hands to review things, or to even decide what a competent gate was for a feature.

This is much more useful.

Projects and developers and maintainers using LLM to review all of the code and the original specs for the architecture to make sure it makes sense and to find things that are just flawed or half baked or “now that we have Llm is this really all you can do?”

I’m actually kind of excited to see more Llm structure in a project as a given for things like Linux, Postgres etc, things that make it possible to find problems early … further left. Actually higher standards for what constitutes code that’s pushed for a project.

We need this bad in the open source world.

Comment by vbezhenar 2 days ago

Maybe for many projects it's time to do a feature freeze. LLM provide a great opportunity to improve testing coverage, run automated code reviews and so on, so basically it's time to improve quality, while developers can adapt to this new LLM world and figure out the proper ways to integrate LLM to the development cycle.

Also adversaries are using abliterated LLMs right now to search for vulnerabilities, so it's important to stay ahead.

Comment by esafak 2 days ago

This is a strong endorsement of postgres; it shows they take quality control seriously.

Comment by PaulKeeble 2 days ago

Seems like this is more about the introduction of LLM code reviews that has found edge cases that would have otherwise been missed and fixed as they appeared over years in the future. The issue is that the volume of issues has been beyond what people could do in time.

Comment by m463 2 days ago

> but now we also already have a few nice 80%-ready features queued up for PostgreSQL 20 that just need those remaining 80% to get done!

This is quite a nice perspective to end up on, and a little humor too.

Some of the beauty of linux that wouldn't happen in corp.

Comment by nubinetwork 2 days ago

> ...you’re staring at a list of like forty defect reports. And even if each of them requires only a three-line fix on average, there is a fixed overhead to dealing with each of these, and then you run out of time.

I'm not sure I understand this, for an OSS project, the only timeframes at play are self-imposed. I don't think most people would care if you pushed a release back by a week to fix some last minute bugs. /shrug

Comment by sublinear 2 days ago

> as far as I can tell, this situation is not due to “vibe coding”. This code was written well before that was a possibility.

Since people refuse to read things on HN, I might as well bubble up this particular bullet point.

Comment by andsoitis 2 days ago

I don’t get the meaning of the article subject.

Comment by DangitBobby 2 days ago

It's a play on "the beatings will continue until morale improves". You obviously can't just beat morale into people, and, knowing that, the audience should understand improvements to a bad situation will not be forthcoming. It's often used for dramatic effect as dark/silly humor when something bad happens.

Comment by andsoitis 2 days ago

Sure, but I struggle to see the similarity being implied between "beatings" and "reverts". Does that make me insensitive?

Comment by jrochkind1 2 days ago

It's acknowledging that reverts are in fact tough on morale, even though better than letting faulty features with rough edges through. I thought it was kind of clever way to just start out acknowledging that everyone's worried about the revert rate, even though the maintainers say it's okay.

Comment by DangitBobby 2 days ago

There isn't really any similarity. Like I said, people use it or make a play on it for dramatic effect when something bad happens.

Comment by LastTrain 2 days ago

It is a play on the old joke “The beatings will continue until morale approves.”

Comment by card_zero 2 days ago

What, the title? "Until morale improves" is ineptly chosen, because it seems self-deprecating: https://quoteinvestigator.com/2020/07/15/morale/

Or if not the title, the general context is this: https://news.ycombinator.com/item?id=50119991

Comment by wodenokoto 2 days ago

I’m not sure I like the headline.

A bunch of features that made it to beta turned out not to be in a state that could be made satisfactory for release time and so was reverted.

That seems to me to be the right thing to do. Unfortunate, but the right thing to do.

“[something] will continue until morale improves” is usually a sacastic dig at tone deaf and incompetent leadership (e.g, “firing will continue until morale improves”)

I don’t think that is fair to say here.

Comment by fc417fc802 2 days ago

Not reverting would have consequences. Reverting hurts morale. It's a bad situation either way. Consider the hypothetical statement "the reverts will continue until code quality improves" while also keeping in mind that the application of popular satirical phrases can be a bit loose at times.

Comment by ranger_danger 2 days ago

[flagged]

Comment by TZubiri 2 days ago

is it really necessary to keep using new version of postgres and to keep developing them? is it not done at this point?

Comment by asdf88990 2 days ago

Yes, not only is there always improvements to existing functionality possible due to changes in improvements in general software engineering and mathematical methods beyond it or supporting new hardware features.

Generally, software engineering like other industries is evolving and there is need for different facilities. Consider graph and vector databases featuring, as well as json columns as examples of things you that are relatively recently in common use.

Comment by TZubiri 2 days ago

> Consider graph and vector databases

sounds like a revolutionary rather than incremental change, does that get into postgres?

Comment by fc417fc802 2 days ago

Yes, postgres has all sorts of features that hadn't been planned on or even conceived of (at least AFAIK) when the project started. It goes far beyond the bog standard SQL queries you'll find in introductory material.

Comment by pak9rabid 2 days ago

Yes. There's always room for improvement.