The article sums up the approach I first read by the c++ spec committee. "pick a date, but not features, or pick features but not a date" I now often have arbi

The article sums up the approach I first read by the c++ spec committee. "pick a date, but not features, or pick features but not a date" I now often have arbitrary release dates for projects, but when I'm asked if x will be included or not I reply I don't know. We'll all find out together on that day. After that date the project gets regular updates (often weekly) with new stuff. Updates are on the "when it's ready" basis. This approach has worked well, when asked I explain the logic, and it seems to satisfy those that need a date (marketing et al) and also those needing features. The former can plan events around the date, the latter know they'll get their pet feature as soon as its ready. Both understand that I have constraints that make predicting unreliable.