| I think,the project tasks should split into two parts in
| order to explicitly who is doing what(that is the most important problem
| of a couple worker).And it should be equal working for each task.
Part of what this project should be about teaching you is how to manage
working in a team, rather than working as individuals. But, yes, to get
things done, you need to divide up the work - you can't both do everything,
that would be insane, nor can one person do everything, that's not the
way things are supposed to work.
But you need to (or should) divide it up amongst yourselves - rather than
having me assign tasks to you, that way you get to see some of the
extra work involved in a non-trivial project.
Nothing you do is ever going to be "equal" - there's no way to make that
happen - apart from anything else, different people do the same task with
different degrees of difficulty (it is harder for some people than others).
That is, if the job gets split into two pieces, that look equally
difficult, or to require equal amounts of work, one person might get
something to do that turns out to be easy for them, while the other
"equal" task is very difficult for the other one. Or, if things get
split so that each does equal amounts of actual work, the result might
end up appearing that 90% of the work was done by one, and only 10% by
the other (because the first found the 90% to all be quite easy, and the
other found the 10% to be difficult).
How to split things and be reasonable depends upon the group - some people
simply prefer to take it in turns to work on the code, each making
improvements to what the other left, adding more, and fixing bugs, then
leaving it for the other to work on next.
Others prefer to each work on their own defined piece, independently.
Each of those has advantages and disadvantages.
As a breakdown ...
| 1. The capture program and filter engine
| 2. The collect program and report gen.
That isn't exactly what I would recommend - first, because (2) is
likely to be quite a bit less work than (1), but also because (2)
can't really do all that much useful until (1) has done a lot (there
has to be at least a definition of what is available to be collected,
and the format it can be obtained, before it makes any sense to think
about how to collect it, or how to put it in files).
If you want to split things, I'd suggest more along the lines of
initially concentrating on just (1) above, with one person handling
the input language, and generation of the internal form of the
specification, and the other taking that and capturing and counting packets,
and then making that available over the net.
That division is likely to be more equal, and while to be useful the
first of those sub-parts needs to generate code for the 2nd to use to
decide what packets to capture, the 2nd part can capture based upon
a hand generated specification to start.
| I'm not sure.Is this suitable,if the project is forked into 2 parts like
| this.So what do you think about this idea?
It shouldn't become two projects - if two separate projects was the goal,
then that was what would have been created at the start - working as a team
(with the extra difficulties and challenges that causes) is part of all
of this - not just producing some code. Once you get outside the
university and start working somewhere, yo'll find that almost everywhere has
teams to do the work, not individuals.
If you're having any problems working as a team, you should talk to me
about them - or perhaps to make it easier for you, talk to one of the
co-advisors (so you can talk in Thai). It is important that any problems
get fixed as early as possible.
วันพุธ, สิงหาคม 11, 2547
เขียนโดย ziddik::zdk ที่ 4:23:00 หลังเที่ยง