3 ms·

"As a dev you don't want to work in an environment where there's some long away deadline for release, that sucks." And yet that's how devs managed for years an

"As a dev you don't want to work in an environment where there's some long away deadline for release, that sucks." And yet that's how devs managed for years and years before CD became even remotely feasible. And some projects are still run that way (I'm working on an open-source project that hasn't had a release in years and is still months away from it. It's a bit frustrating, but I can't see the situation being improved by pushing out a release before it's ready).

duped 4y ago
Personally I don't defer to past practices as absolute wisdom. I've worked in waterfall environments and don't really want to go back. I like to be able to take vacations whenever I want and not stress about deadlines or go through crunch again. The problem to solve is defining partial success as ok. If your product needs a whole set of discrete features to be releasable instead of an MVP set of discrete improvements and quality checks against regressions then something is off in the management and testing structure of the project. The nightmare scenario I want to avoid is a user base that needs improvements and those improvements being done but releases blocked on things other users need. You don't want to delay things that can be valuable today once they work - that's bad for everyone.
- wizofaus 4y ago
  TBH in this particular case the project manager would be the first to admit that the current release (which was a substantial rewrite of an already functionality-super-rich product) was way too big a piece of work to do in one go. But there was really nothing that could have reduced the time between the releases much below 6 months or so. I certainly wouldn't call it a "waterfall environment" though! To be fair we are doing regular nightly builds that are accessible to the public, but they're very much pre-alpha and buyer-beware type builds that don't pretend to be suitable for most users.

duped 4y ago

Personally I don't defer to past practices as absolute wisdom. I've worked in waterfall environments and don't really want to go back. I like to be able to take vacations whenever I want and not stress about deadlines or go through crunch again. The problem to solve is defining partial success as ok. If your product needs a whole set of discrete features to be releasable instead of an MVP set of discrete improvements and quality checks against regressions then something is off in the management and testing structure of the project. The nightmare scenario I want to avoid is a user base that needs improvements and those improvements being done but releases blocked on things other users need. You don't want to delay things that can be valuable today once they work - that's bad for everyone.

wizofaus 4y ago
TBH in this particular case the project manager would be the first to admit that the current release (which was a substantial rewrite of an already functionality-super-rich product) was way too big a piece of work to do in one go. But there was really nothing that could have reduced the time between the releases much below 6 months or so. I certainly wouldn't call it a "waterfall environment" though! To be fair we are doing regular nightly builds that are accessible to the public, but they're very much pre-alpha and buyer-beware type builds that don't pretend to be suitable for most users.