Re: [Mailman-Developers] [GSoC 2012] Metrics
Steve,
I will take the blame for any misunderstanding in this area.
The GSoC calendar is based on the assumption that the students will have completed their spring academic work prior to the serious coding phase.
Since conditions in Greece have delayed George's academic year, his "spring" final exams will now occur during the summer. I suggested that, in order to meet his mid-term goals in a timely fashion, he might expend some extra hours now, hopefully be ready to start coding a little early, and then be able to take a planned period of reduced effort during his finals.
I am not, in any manner, suggesting that he skip any steps in the process.
Richard
On Thu, May 3, 2012 at 8:04 AM, George Chatzisofroniou <sophron@latthi.com> wrote:
I’m also thinking to rearrange the GSoC schedule a bit. I’ll start writing code on the bonding period,
It's up to your coding mentors, but it's generally not a good idea to try to move up the coding stage by too much. Make sure you have a clear spec before you start coding anything, and at least a rough sketch of a design. Without those two pieces, there's no standard to evaluate progress, or whether your code is doing the right thing.
so i can have more time during my university’s exams (starting on half of June).
I'd say just take the time as needed, after negotiating with your mentors.
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.
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.
Richard Wackerbarth writes:
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.
I bow to your superior experience in the field (there are no "large projects" needed in mine! ;-)
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.
I see. So the idea is that that's the stage that George is at anyway? He "built one to throw away", and now it's time to progress to the reimplementation? (I forgot about that aspect; indeed, the fact that he's already built a project similar to this one should speed up the planning and design stage.)
participants (2)
-
Richard Wackerbarth -
Stephen J. Turnbull