4 ms·

> The experience of Firefox and Chrome is that long release cycles actually decrease quality, precisely because of the dynamic on display here: long release cyc

by dimino 11y ago

> The experience of Firefox and Chrome is that long release cycles actually decrease quality, precisely because of the dynamic on display here: long release cycles create huge pressure to land under-done features just before a deadline. With date-driven short release cycles, if you're not confident in your feature you'll be happy to just slip it to the next release. It greatly reduces stress on developers in general. This comment really resonates with me, and wasn't something I thought of -- the pressure to deliver when your release cycle is so infrequent is something I hadn't noticed before but once mentioned, realize it's absolutely true.

hyperpape 11y ago
In my experience, this is not the case if you have short release cycles combined with hard commitments. I work at a company that does enterprise software that releases every 8 weeks, and there are still problems when we commit to shipping a feature for a particular release.
- techdragon 11y ago
  The nominal word being commitment. If you commit to the feature you haven't been able to take advantage of the short window to make "letting it slip" a less painful option.
  - hyperpape 11y ago
    I agree.
mook 11y ago
Unfortunately, it seems like short release cycles can also lead to buggier released; after all, who cares, it'll all be fixed in eight weeks or whatever, right? It's not like people will be using the broken thing for a year. Of course, the next release will then have a _different_ minor bug. Then the pattern repeats.
- organsnyder 11y ago
  I don't think that long release cycles are the solution for this, though—major x.0 releases are well-known for often being buggy themselves, after all. I think that buggy releases speak more to problems with general project management and priorities than to the release schedule used.
- ozten 11y ago
  Missing a train isn't a big deal if it's every 6 or 8 weeks, so you can delay or stay feature flagged off until the next train leaves the station.
- sitharus 11y ago
  They can, but in my experience they don't. If you release every two weeks and something isn't fully signed off at the end you don't release it - it's only two weeks until the next one. If you release every three months you cram in everything you can because it'll be at least three months until the next release. Of course it's only true if you treat releases as an opportunity, not a constraint. If you don't promise dates but keep the opportunities frequent you get more done.
- davidgerard 11y ago
  This is not how it works out in practice, at all. In practice, the slow release cycle works out worse.
janee 11y ago
> the problem would be in supporting many more versions things like backporting fixes and maintaining upgrade paths are extremely expensive in the long run from my experience, something that I think short release cycles would exacerbate. I think it comes down to what's mentioned in response to the comment about short release cycles: people are reluctant to upgrade an RDBMS because of the risk involved and expense to test compatibility with a new release. I dunno maybe the problem is finding the shortest release cycle possible without putting people off and adding too much overhead?
deadbunny 11y ago
I can't remember where I read it but someone stated something similar about train scheduling (I'm paraphrasing here); When the train departs every 15 minutes getting the train becomes a non issue, when the train departs once an hour it becomes an ordeal.
teacup50 11y ago
Short release cycles don't solve this problem. If anything, they exacerbate it -- you can just fix any bugs in the next release, right? On top of which, they incur heavy user cognitive costs when tools change every few weeks. Short release cycles seem to be more about making developers happy by alleviating them of a weighty responsibility, rather than making users happy by shipping something that stands on its own as a solid, well-made product that doesn't need a stream of constant updates. I want software to behave more like reliable products that have survived the decades in the real world: they work as advertise, and they keep working. This is something PostgreSQL has achieved for many years.
- davidgerard 11y ago
  Users want magical flying unicorn ponies, but short release cycles still work out better than long ones, because you can delay questionable features just a few weeks instead of a year.
  - teacup50 11y ago
    That might make sense for the next omgchatpopapp, and it might make the marketing department happy to have a constant stream of feature noise, but that's not a universal truth, and I'd rather optimize my practices for practicing my craft with responsibility and care for the future. Churn doesn't make sense for PostgreSQL; people who rely on software as a tool to accomplish their work generally do not benefit from incomplete poorly considered "minimum viable" solutions and a constant stream of instability. Strategies like continual delivery -- or focusing on MVP -- optimize for quickly proving/disproving user traction at a minimum possible expenditure, as to more quickly reach a stage where further growth can be funded via more investment. In the process, these strategies incur a high percentage of false negatives -- including ideas that could work if given more consideration and care. These strategies are ultimately about exit events, not making well-crafted products that stand the test of time. Ironically, the latter is what often leads to much more substantial renumeration.
    - davidgerard 11y ago
davidgerard 11y ago
It's one of the central platforms of open source software: "release early, release often." Time-based releases work to get your software in order. See Linux and Libreoffice as well. https://en.wikipedia.org/wiki/Release_early,_release_often https://en.wikipedia.org/wiki/Release_early,_release_often
Sanddancer 11y ago
When you're maintaining a database server, though, the pressures of keeping it up are much greater than a simple web browser. It may take several weeks just to do all the regression testing on the development and staging servers, several hours to do a dump from the production server, running the manual migration steps, and then bringing the server back up. A six to eight week train type schedule for a database would be more than a bit painful for an admin, especially if point release bugfixes are ignored in favor of just putting the patch in the next release.

by dimino 11y ago

hyperpape 11y ago

In my experience, this is not the case if you have short release cycles combined with hard commitments. I work at a company that does enterprise software that releases every 8 weeks, and there are still problems when we commit to shipping a feature for a particular release.

techdragon 11y ago
The nominal word being commitment. If you commit to the feature you haven't been able to take advantage of the short window to make "letting it slip" a less painful option.
- hyperpape 11y ago
  I agree.

mook 11y ago

Unfortunately, it seems like short release cycles can also lead to buggier released; after all, who cares, it'll all be fixed in eight weeks or whatever, right? It's not like people will be using the broken thing for a year. Of course, the next release will then have a _different_ minor bug. Then the pattern repeats.

organsnyder 11y ago
I don't think that long release cycles are the solution for this, though—major x.0 releases are well-known for often being buggy themselves, after all. I think that buggy releases speak more to problems with general project management and priorities than to the release schedule used.
ozten 11y ago
Missing a train isn't a big deal if it's every 6 or 8 weeks, so you can delay or stay feature flagged off until the next train leaves the station.
sitharus 11y ago
They can, but in my experience they don't. If you release every two weeks and something isn't fully signed off at the end you don't release it - it's only two weeks until the next one. If you release every three months you cram in everything you can because it'll be at least three months until the next release. Of course it's only true if you treat releases as an opportunity, not a constraint. If you don't promise dates but keep the opportunities frequent you get more done.
davidgerard 11y ago
This is not how it works out in practice, at all. In practice, the slow release cycle works out worse.

janee 11y ago

> the problem would be in supporting many more versions things like backporting fixes and maintaining upgrade paths are extremely expensive in the long run from my experience, something that I think short release cycles would exacerbate. I think it comes down to what's mentioned in response to the comment about short release cycles: people are reluctant to upgrade an RDBMS because of the risk involved and expense to test compatibility with a new release. I dunno maybe the problem is finding the shortest release cycle possible without putting people off and adding too much overhead?

deadbunny 11y ago

I can't remember where I read it but someone stated something similar about train scheduling (I'm paraphrasing here); When the train departs every 15 minutes getting the train becomes a non issue, when the train departs once an hour it becomes an ordeal.

teacup50 11y ago

Short release cycles don't solve this problem. If anything, they exacerbate it -- you can just fix any bugs in the next release, right? On top of which, they incur heavy user cognitive costs when tools change every few weeks. Short release cycles seem to be more about making developers happy by alleviating them of a weighty responsibility, rather than making users happy by shipping something that stands on its own as a solid, well-made product that doesn't need a stream of constant updates. I want software to behave more like reliable products that have survived the decades in the real world: they work as advertise, and they keep working. This is something PostgreSQL has achieved for many years.

davidgerard 11y ago
Users want magical flying unicorn ponies, but short release cycles still work out better than long ones, because you can delay questionable features just a few weeks instead of a year.
- teacup50 11y ago
  That might make sense for the next omgchatpopapp, and it might make the marketing department happy to have a constant stream of feature noise, but that's not a universal truth, and I'd rather optimize my practices for practicing my craft with responsibility and care for the future. Churn doesn't make sense for PostgreSQL; people who rely on software as a tool to accomplish their work generally do not benefit from incomplete poorly considered "minimum viable" solutions and a constant stream of instability. Strategies like continual delivery -- or focusing on MVP -- optimize for quickly proving/disproving user traction at a minimum possible expenditure, as to more quickly reach a stage where further growth can be funded via more investment. In the process, these strategies incur a high percentage of false negatives -- including ideas that could work if given more consideration and care. These strategies are ultimately about exit events, not making well-crafted products that stand the test of time. Ironically, the latter is what often leads to much more substantial renumeration.
  - davidgerard 11y ago

davidgerard 11y ago

It's one of the central platforms of open source software: "release early, release often." Time-based releases work to get your software in order. See Linux and Libreoffice as well. https://en.wikipedia.org/wiki/Release_early,_release_often https://en.wikipedia.org/wiki/Release_early,_release_often

Sanddancer 11y ago

When you're maintaining a database server, though, the pressures of keeping it up are much greater than a simple web browser. It may take several weeks just to do all the regression testing on the development and staging servers, several hours to do a dump from the production server, running the manual migration steps, and then bringing the server back up. A six to eight week train type schedule for a database would be more than a bit painful for an admin, especially if point release bugfixes are ignored in favor of just putting the patch in the next release.