[wp-hackers] 120-day release cycle

[Daniel Jalkut]

Hi Bryan:

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  
soon time.

> 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
> deadline.

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  
> change.
> 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  
> feature)
> just isn't up to snuff.  Right now, WordPress would just slip the  
> time/speed
> 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
> deadline...*

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  
budget :)

> 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  
> that
> 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.

Daniel
(an opinionated more-or-less outsider)