Re: Spec organizations and prioritization

On Thursday, 22 March 2012 at 13:57, Marcos Caceres wrote:

>  
>  
> On Thursday, 22 March 2012 at 13:52, Julian Reschke wrote:
>  
> >  
> > OK; here's another data point. HTTPbis started as RFC 2616, split into  
> > seven pieces. After the split was done, the modularization essentially  
> > creates no overload at all, but makes maintenance much easier; in  
> > particular with multiple authors working on different parts at the same  
> > time.
>  
>  
>  
> When did the work start? When is the estimated completion date? I guess we then compare that to start-end dates of RFC2616 itself?  
>  
I'll note that this is not really that different from saying "you three work on sections X, Y, and Z, and I'll work on section A" VS "you three work on spec file x, y, and z, and I'll work on spec file A". The point about editorial staff and parallelism is worth investigating; but sometimes, throwing lots of people at a problem sometimes makes things worst… I can't remember what that law is called, but it's close to the law of diminishing returns. From wikipedia:

"A common sort of example is adding more workers to a job, such as assembling a car on a factory floor. At some point, adding more workers causes problems such as getting in each other's way, or workers frequently find themselves waiting for access to a part. In all of these processes, producing one more unit of output per unit of time will eventually cost increasingly more, due to inputs being used less and less effectively."

http://en.wikipedia.org/wiki/Diminishing_returns


--  
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 22 March 2012 14:05:57 UTC