[wp-hackers] 120-day release cycle
jalkut at red-sweater.com
Thu Oct 5 15:12:59 GMT 2006
On Oct 2, 2006, at 4:32 PM, Brian Layman wrote:
> I expect everyone here knows the axiom:
> "Speed (of the release), Quality (of the release), Price (of the
> release) -
> pick two"
I love that quip - it makes a lot of sense in a lot of specific
instances. Unfortunately, it leaves a lot of unspoken, but
intrinsically associated factors out. The tradeoff on each of those
three points only makes sense as they relate to *other* unspoken
attributes of a given project. For example, two major elements are
"feature requirements" and "cost of operations." With an
operational cost that approaches zero, you can afford to have the
price also be zero. With a zero complexity feature set, you can
afford to release something of highest quality, and at an arbitrarily
> The "price" or "cost" is already set for WordPress release. This is a
> volunteer project. The people working on the core now, are gonna be,
> roughly, the same people who are working on it under a 120 day
> schedule. In
> fact, a few people might drop off as it moves from sounding like
> fun to
> sounding like work. It could go the other way too, I suppose; I
> guess we'll
> see. But chances are that full time people are not gonna be hired
> just to
> meet that 120 day goal. I could be wrong, but I don't think there's
> gonna be
> an extra 10 or 20 grand tossed into the pool to increase the workforce
> temporarily. So, the "price" of a release is set.
> The "Speed" of the release will now be set too. 120 days. Period.
> A hard
Interesting deduction, especially if we did believe that those three
attributes were truly the only guidelines shaping a product release.
> That means that it is only the quality of each release that will
> I'm not saying that the schedule will make the release buggier.
> What I am
> saying is that you'll eventually have to make some hard choices
> about some
> desired feature being dropped because it simply aren't ready for
> prime time.
> That could make a release very thin - if a major feature (the major
> just isn't up to snuff. Right now, WordPress would just slip the
> of the release and fix the problem. The 120 day hard release would
> eliminate that possibility. That is if you are saying it is a hard
My intrerpretation of Matt's suggestion is that the 120 goal would be
more a "hard guideline." I don't think anybody is going to want to
ship a release just to get it out in time, if it's a piece of crap.
> If it is a 120 day "goal", that makes life a little easier. You
> shoot for
> 120 days, but it might be 140 or 150... That's probably better
> than what is
> done now. It is a still a jump to the other side of the scale, but
> it is
> probably more realistic...
And it might be 110 days. Not all software development has to go over
> All of this is to say, that you really need to decide now, how you
> want to
> handle that choice you'll eventually face. Is it: 120 days is 120
> days is
> 120 days; features be damned**. Or when push comes to shove, will
> you, 1
> month out, choose to continue to work on the next big thing even
> though you
> have significant problems in it still and you know you might not get a
> quality code freeze. Something for Matt and Ryan to think about...
My reading of this is that when the "fun chaos development time" is
over, project leaders will hunker down and evaluate which of the fun
chaos is actually in good enough shape to polish up and ship within
the next 2 months. So there's still quite a lot of opportunity to
wisely choose achievable features.
And with a more frequent release schedule, anybody who was close to
finishing a feature, but it wasn't quite stable enough, wouldn't feel
as much pressure to just "sneak it in," because the wait time for the
next release wouldn't be so far away. I'm not familiar enough with
WordPress's code base history, but in general I could see this as a
stabilizing force for quality.
> (* Additionally, with a young project like WordPress, the features
> come fast
> and furious. As the project matures, you're gonna have to start
> thinking a
> little more strategically and put more time into planning. Plus big
> features will need to be worked on for a longer period of time and
> takes resources from the current release. That 2 months of free
> for all
> development will be eaten up by more and more design time as the
> future robs
> from the present resources.)
> (** Sorry - I don't swear, but nothing else fit there and the literal
> meaning applies...)
Thanks for sharing all of your interesting thoughts on the subject. I
think they are definitely worth considering, even though ultimately I
think the 120 day schedule will be a great a boon to the project.
Operating under constraints always seems to help.
(an opinionated more-or-less outsider)
More information about the wp-hackers