[Mailman-Developers] [GSoC 2012] Metrics

[Richard Wackerbarth]

Steve,

I am in complete agreement with your points about adequate planning.

However, I rarely see large projects that do enough "research" to plan things properly from the start.
Usually, a few people, who think that they understand the whole problem, make early design decisions that often become obstacles in the future. It is only after the prototype has been developed that others are able to point out weaknesses in the initial design.  As such, I advocate for a planned "revise during implementation" to the extent that you schedule a reimplementation for a new generation of the product rather than continually attempting to "add on" to the previous design. 

Richard

On May 4, 2012, at 4:36 AM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> I will take the blame for any misunderstanding in this area.
> 
> There's no blame to be assigned, really, unless to me for being a
> busybody. :-)  If George is making these plans while consulting his
> mentor, that's what this is all about (but he didn't say that, so I
> stuck my nose in!)  And maybe I misinterpreted the word "coding"
> which, as I continue to explore the GSoC documentation, seems to be a
> catchall for "GSoC work".
> 
> It's just been my experience in supervising economics and business
> students' research (confirmed by a lot of the academic and practical
> literature on managing software development) that people facing a
> scheduling issue tend to skimp on planning, hoping to get lucky with a
> first draft and as a backup, planning to revise during implementation.
> This doesn't usually save time in the end, and often ends with a lower
> quality product.
> 
> How George chooses to accomplish the planning, design, and coding, I'm
> happy to leave up to him (and you).  I just wanted to warn against
> hoping that producing a plan and design more quickly than he otherwise
> would will save time.  Time taken liberally in the early stages will
> conversely probably save time later.