Fall 2007

There were a few initial teething problems with regards to getting excited about the project, thinking about whether it was even possible and actually getting down to business. It seems that there were a few communication issues at the start as well, as expected, as people started thinking about getting organized.

Once organization was attained and team leaders and such were nominated, progress was much smoother. People also became more comfortable with using their human resources rather than banging their heads against the wall or searching with no luck on Google.

Journals also became more detailed and as a result misunderstandings were ironed out at a fairly early point.

In short it seemed like there was initial caution, confusion, organization, anger, frustration, work, happiness, and fond reminiscing...in that order somewhat.

To expand on that, though, is to say the following:

There seemed to be initial caution due to a lack of a clear understanding as to what needed to be done to fulfill the project within its specifications, a lack of clear milestones, and a lack of communication. This, of course, leads to confusion. That brought about the need for organization. And organization seemed to be had, apparently with a great leader and a strong group bond. But the pressure, and miscalculations (be they from lofty milestone expectations, or simple slacking) would lead to frustration and anger. Both of which lead to the dark side...er...well, to be poignant they simply stress the group dynamic. But angers abided, tears swept away, and the group was able to function better having a better understanding for the need for communication and importance of both morale as well as group functionality. This was to keep steady until the end where we are now left with the advice and knowledge of the past.

But that's almost too elaborate, and too intricate in detail. I think that the greatest general feeling was that the learning to be had from the class was not about programming nor coding styles nor even the need for documentation (as almighty and important as it truly is). That is not what makes this class - learning group dynamics, teamwork, and responsibility (both as an individual and as a group) in a real-world setting is what will make up this class. These are not things that can be taught out of a book by any means, and if there were a class on the subject, COMP 410 will be one of the (if not THE) class that drills it into you.

Trial by fire. I'm kind of excited, at least.

From the journals, it appears that communicating effectively and keeping everybody on track were issues that popped up all semester. There was a great emphasis on how to manage the entire group and ensure that everything got done. Once the group figured out how to dole out tasks to everyone, it seems like things might have run a little smoother. Coding seemed to be the least of their problems.

At first, people loosely split up into groups and began work on their stuff independently. This worked at the beginning, but it seems that at some point they realized that there was a pretty significant lack of communication and central leadership which made it difficult to progress together.

The team leaders began to take charge and CLEARLY define milestones and to-do lists which I think is crucial to the success of the project.

I think the most important lesson learned is that EVERYONE has to be on the same page or people and code is going to get lost and tensions are going to grow. The ways to do this are definitely to have a central leadership that can monitor the progress of all teams and can delegate tasks as he/she sees fit.

Another important part that I think the class struggled with last year was the presentations they had to do both to each other and to the customer. At the end, I think the best idea they had was to have each individual make part of the presentation (given a template) for what they had developed and then have someone smoothly put it together. It allows everyone to synthesize what they've done so far and if you assign a different person to put it together, it allows people to stay on top of what everyone else is doing.

Another way that I think they succeeded in getting everyone involved is to send different people to the customer meetings every time. Even though it may not have gone smoothly every time, it forces the attendees to learn what's going on in every group and it seemed to work in motivating people to work hard.

For the most part, classes seemed to jump right into coding without enough design work. Also, there were complaints about not enough testing, human redundancy (i.e. people did not know each other's code well enough to work on it if need be), communication (and correct management of communication data), and the ilk. Most complaints seemed to center around a lack of communication, planning, proper time allotment, and other things that center around teamwork rather than individual work (although some journals did mention to be wary of people burning out, and to plan and adjust for this danger).
Oh, and it seems that there should be at least one person alloted for documentation and presentations as a main duty (replacing some of the programming load).

The project seemed to get off a to very slow start in terms of getting the project off the ground. It wasn't until the "customer" asked for a proof of concept that many realized other parts of the project should already be in place, including design and pre-documentation. Most people seemed more focused on individual efforts, which became a problem when they needed to patch their work together.
In general, the team seemed to be divided into those enthusiastic about the project, and others who seemed to be distracted by other things, which created a drag on what work could be accomplished.

It seems like in the beginning people had difficulties organizing meetings. Later, I could see that people enjoyed their coding parties and working together. Tasks given to different teams were also uneven in size in the beginning, but estimating how long each subtask would take got better as time progressed.

At the beginning people were not familiar with the project and they didn't know what should be done. The meetings were not well organized.
Later, as tasks were distributed to groups and individuals, everything seemed to be well.
At the end of the semester, they didn't have enough time to test and debug the code.

As it's sort of supposed to, everything fell apart. There appeared to be a number of people who were slow at getting there work done, and those that knew things were falling behind weren't open enough about it. Also, there didn't seem to be a good plan from the beginning, so production went down many different roads before some real decisions were made.

Although I only read last year's journals, they reflected what I've heard is the pattern of every 410 class. In the beginning, there is chaos. When deadlines start passing, people realize that chaos doesn't work, and a more refined system of organization is born. However, the chaos at the start led to poor design and documentation, and at the end there is a massive amount of effort needed on everyone's part to make the system come together by the final deadline. It all seems to work out in the end, though...

It seems like the class really is about group dynamics, communication, and effective design and planning than anything else. Most of the mistakes came about through problems with the above, rather than through problems in the programming language or techniques. While those kinds of hurdles do inevitably arise, they seemed straightforward to address when the planning and communication was there (though not necessarily without any sweat), and became truly problematic when they weren't. This is one of the constant themes that crops up in the "Advice for next year" section.

It sounds like they had some serious interpersonal conflicts. Just reading the journals claiming that about half the team was working well while the other half didn't ever take ownership indicates there was a major disconnect within the team about what was expected and what level of commitment they came through with. It still looks like the pulled through by the hard work of a few people to make something effective, and they clearly learned a lot.

It seems like the class was mostly about communicating with one another clearly and pre-planning. Planning in detail was/is key, for the UI and code design both. It was important to know what was necessary and what was not, so as not to spend too much time on parts of the project that were not as important as others. It seemed like there was a lot of problems with communication and planning of this sort, and that is where most of the problems and learned came from.

The biggest "mistakes" being made were (1) communicating ineffectively within a team or with the customer, (2) allocating resources efficiently and effectively and (3) not being accountable for required work. These were big mistakes because they slowed down overall progress, rather than progress in just a given module.

Of all the things that were stressed (both in writing and in the other sense) the one to pick out would be communication. There seemed to be a lot of stress and perhaps unnecessary issues that came up with a lack of communication. We should definitely make as much use of sharepoint as possible this semester, possibly even set up many systems to aid it. An IRC channel was suggested in the Monday meeting, and there are many more options as well - wikis for example may be possible if SharePoint becomes exceptionally unruly to our needs.

Of course it's not fair to just say "communication" like that. It's such a broad subject, and to pick out specific examples is both unfair and (as I feel) not my intended purpose for this section. Suffice to say, the problems can be many, but the solutions can be many as well. I'm glad that we're having icebreakers at our meetings and that we're all feeling more comfortable with speaking with each other. From a personal experience, I've had jobs where I've had issues with coworkers all stemming from a lack of talking things out with each other. It's important not to let things build up as such.

I think at one point there was a customer meeting in which they presented features that looked really nice, but which were not in fact completely implemented. This seems to have led to a lot of angry people, probably within the team and without. The lesson to draw from this mistake is that communication, at all times, must be clear and unambiguous. Expectations need to be stated explicitly and people must have no room to wiggle out of their given duties.

It seemed like everyone was working very independently at first. This definitely translated into headaches later when things weren't necessarily meshing well together. I think it's important to have meetings where everyone can be on the same page and where everyone pays attention to what the other teams are doing.


A lot of people resorted simply to Google than asking people which can be a mistake, since we have so many resources.


Apparently, at first coding parties were very disorganized -- you need someone to come up with an agenda and take charge or coding parties are going to be kind of useless.


Long weekends apparently caused problems of staying focused and working. This is definitely hard to fix, but it's important to keep in mind.


Their biggest problem in the middle of the semester was people lying about what they had done. Although it can be scary to admit that you failed the team, it's better to admit it early than attract all of the team's rage once they realize you lied to them.


Non-team leaders seem to not know what the milestones were about, or what was decided by the team leaders so definitely minutes or some sort of summary of team leader meetings is imperative.


Sicknesses seemed to create problems very often, especially when the team leaders were sick. All team leaders need to have delegates that can take over when they get sick and people need to realize that they can also work without a head (people need to step up without being told to do so).


When one person didn't do the work they're supposed to do, everyone exploded. While this may make that person begin to do the work, it shifted everyone's focus from working as a team to hating one person as a team. It can be hard to keep a calm head, but getting angry is not a good way of conflict resolution.

It seemed like there was a disconnect between leadership and a few of the team members. The leadership seemed to have a very good understanding of what needed to be done and how everything fit together, but others had a very murky view of what the overall view was.
It seemed like many issues outside the project derailed certain efforts. Illness, other classes, and schedule conflicts all hampered deadlines, meetings, and milestones.
There seemed to be an over-reliance on certain team members to the point where hardly anything could be done without them. This caused both stress on the individual in question and allowed others to get by with less effort.

Some seemed to have been not so cooperative or considerate of others' time. I saw angry comments and criticisms directed towards certain people in the class. (Gosh, I hope we never get to that point this semester!) I think it's important to be able to work well as a team so while I wouldn't call this a "mistake" per se, it was something that hindered the class from forming a good development environment.

People always complain about communication among group members. Sometimes they disconnected with each other and didn't know others' progress. Sometimes team members were not clear about their tasks.
Code is not well tested until the last minutes. It seemed they ran out of time, so they didn't have enough time to test the code.
Code is not well documented. People didn't understand others' code and had problems trying to modify it, which slow down the progress.

Obviously people not getting their work done is a big one, but that's more of an individual mistake than for the team. What others could have done is encourage those people to actually do their work (in whatever way possible). But also, there are some more positive ways that can reinforce this; giving specific tasks and/or deadlines works for some people. The trickiest bit about this is what works for some doesn't for others.
I feel like there was a distinct lack of focus on the part of the team. People really only worked when everyone was together and they sort of had to. Details should have been ironed out before work commenced, reducing or eliminating the period where everyone sort of does their own thing (we had a bit of that in the warmup project for the first week).
Also, it looked like they weren't doing much in the way of documentation, in terms of meeting notes, or reasons for decisions, or just information in general (that may need to go to people that can't be at everything). I feel like we've already started to fall into the same problem a little bit.

A great number of people claimed that communication was their greatest problem. Some people would take too much on and would create large parts of the system singlehandedly, while others wouldn't work hard enough, and thus became less and less able to understand the total project.
Integration and testing also seemed to be a problem; it would happen too late, as people greatly underestimated the amount of time it would take.

The biggest mistakes made almost always involve a failure to communicate or a false assumption. There were minor miscommunications, where team members missed meetings because they didn't know the start time, and major ones, where a presentation poster didn't end up looking the way that several teammates felt had been discussed during a meeting. It is mentioned over and over that not setting specific, clear milestones results in work that didn't meet the true needs and meaning of the project. That is a failure to communicate. I would also put things like "we thought of X but forgot about it later" in this category (a failure to write it down and thus communicate with ourselves).
I think the false assumptions can be even more insidious, because it is difficult to realize when you are making one. The two that come to mind are groups that assumed they would be able to reuse code from previous years, and a repeated mention of failure to try to integrate code from different sub-teams soon enough - a false assumption that integration would be fast and simple. I think this is an issue that will take some vigilance and perhaps outside soundboarding to combat.

I'm not sure what Alex did, but it must have been a massive error. Reading the journals just after this, it seems that he just skipped or edged his way out of doing a milestone while everyone else was waiting up all night doing theirs.

It appears that one of the biggest warnings to us is to be abundantly clear about the milestones, giving full detail so that members can't weasel their way out of really doing work.

Another problem seems to have been inadequate communication of the overal model, plus too long of a wait to integrate things together, as several people vehemently recommend forward integration.

It's hard to tell also, but it appears that they had some level of disconnect between those dealing with the customers and those writing the code. While to a degree this allowed them to have people dedicated to appeasing the customer, at the same time it also sometimes let the developers escape some of the blame for badly working code. Also with this it sounds like understandig the exact feature set expected by the customer could be something of a problem.

-Everyone didn't understand all parts of the code, and made trouble when someone other than the creator needed to modify it.
-Didn't use forward integration
-Didn't clearly communicate the exact obligations of someone in a milestone.
-Forgot some of the "cool features" that could have been added, which would have made the project more fun.
-Being prepared for the customer meetings/presentations
-They went into a presentation making it sound like they had more done than they did.

(1) Communication was improved by breaking down into smaller teams once it was found that it was hard to conduct fruitful discussion in large groups. A person to record minutes was appointed fairly quickly in the course as well. I'm not sure that they ever really improved communication with the customer, but there certainly seemed to be a slightly better understanding towards the end, and fewer ill-feelings toward him. Journals also became more detailed towards the end and Sharepoint looked quite utilized, if a little unorganized.

(2) Project managers were appointed to allocate resources. It seems like one problem which was not fully removed was hero-coders, but a decent attempt was still made under the prodding of the course staff.

(3) It looks like people began letting others know of their situation either by Sharepoint or otherwise more than at the beginning. Project managers were especially essential for this as the smaller team members were expected to report to their project manager at every meeting.

Elaborate use of SharePoint helps greatly. Meetings, meetings, meetings. Group bonding. Establishment of communication lines. Even using group members as liaisons between nonempty subgroups is a good idea. Why these work, to me, seem to have to do with group dynamic. They help maintain checkpoints, clarify all points when necessary, and allow the group as a whole to function efficiently.

It seems like lots of communication, frequent group meetings, and finding someone to manage the team as a whole and get everybody motivated were crucial to resolving problems they encountered.

I wrote some of the things they did in the last question...my bad, but here are some other general ones that I noticed and stuck out.


In my opinion, the most important thing that they succeeded in last semester and also the most important thing they learned is the importance of someone that can roadmap what needs to be done and to SPECIFICALLY delegate tasks by week to different groups. People seemed to work A LOT better when they knew exactly what their tasks were and by when they needed to be completed.


Another important barrier that they seemed to get over was the communication between people doing different things. One of the best things I saw was the weekly reports that Chelsea compiled and put together on Sharepoint for everyone to stay up on and understand. Along these lines, the Show-and-Tell presentations during class time also helped with visualizing what other people had done.

Each bullet point here corresponds to one of the ones from above, so I don't have to repeat the problem to write the solution.

• Since this problem came up so early, it seems that a lot of groups had to go back and redo a lot of work and code after re-establishing a stronger design. Also, apparently forward integration (starting by creating the system in which pieces will communicate and work together rather than first creating the pieces and trying to put them together) is supposed to be quite effective and useful
• This was rectified, in most cases, by having more meetings, making better use of Sharepoint to compile data, standards, and information rather than leaving it to individuals to try to keep track of all of their own stuff, i.e. not reposting information that came up in a verbal conversation or one that took place in a chat room/instant messenger.
• Late testing, which is not as good, but helps.
• Mostly this was fixed by allotting time later, which once again isn't as good as allotting it early, but is about the only recourse, excluding time travel. Oh, and panicking and working long hours very hard. Apparently that is also a recourse for things going wrong.

Also, it seems we should make liberal use of the coffee/pizza budget. This actually seemed to come up a surprising number of times...I would never have guessed that a bunch of college students would NOT make liberal use of such a budget.

They eventually grew more knowledgeable about eachother's schedules (CS majors are not early birds!) and could plan more regular meetings.
The group leaders and managers made a very real effort to make everyone have a better understanding of how their roles fit with the others, and how crucial adherence to goals and deadlines were.
The hero coders realized how detrimental the situation was and delegated more work to others.

Communication is vital in working in a group setting. Some are writing more specific journal entries as time goes by and that seems to help a lot. They are learning to distribute workload more evenly as time goes by and appreciating and taking advantage of time spent together working on the project (as well as the free pizza!) Positive attitude and active communication and being specific always makes things better!

Some meetings, code sessions are effective and well organized, which improve the communication. Splitting into small groups also help improving the communication. Well written journals helped them to understand what other people are doing.

You can't run a team effectively with all chiefs or all indians, and when they established leaders, planning seemed to come easier. Deadlines could have potentially been more strict, and intermittent, in order to keep everyone working at a reasonable pace. I know that I personally wait until deadlines to really crack down on something; setting deadlines every week or even every few days could work well here and be a substitute for individual planning and goal-setting.
It doesn't look like they really got their act together with the documentation, until perhaps the very end. We need to make sure and do our best now, so that towards the end of the semester when we're freaking out about shipping our product, we try to live up to the standard that we've already set. It's really easy to have a meeting and make a lot of progress and decisions, but it's also easy to forget all that progress hours after the meeting. Writing everything down is a task everyone hates to be stuck with, but it's absolutely crucial. Similarly for code and high-level documentation.

Eventually, the hero coders ran out of steam and were forced to delegate their responsibilities. Integration, testing, and all other problems seemed to more or less be conquered by a large and unpleasant last-ditch effort.

The stand-out solutions for communication problems were creating a clear decision making process and an effective way to both disseminate and archive information. The role of the PM was mentioned over and over, especially in the advice sections. There were various communication strategies from email to the sharepoint site mentioned, but the most important one seemed to be clearly documenting not only code, but decisions made, milestones assigned, and standards agreed upon.
The solutions to false assumptions that I noted really only seemed to be after the fact. For example, failure to allot for proper integration time was solved by spending emergency coding sessions getting everything integrated. Re-writing of code was used to solve problems with reuse. But there were better solutions suggested for later classes - "integrate early and often" was suggested many times, and willingness to abandon strategies that aren't working before too much time is spent on them was also advised.

It appears that the interpersonal problems were resolved by a healthy share of apology and forgiveness (and perhaps changed behavior) on each side. Still there's a definite sense to the final journals that many people came away feeling burnt by the process, and feeling that there were members who didn't pull their weight.

The level of ire is suprising and even shocking considering people usually don't get SO emotional about CS projects in my experience. I suppose cooler heads prevailed in the long run, but even speaking of death threats seems a little extreme.

As far as communication, I can only assume that the incidents they had led to them stating objectives and milestones more clearly, checking on expectations, ensuring that everyone had the adequate resources, and encouraging team player-ship by working together.

It also appears that increasingly Hy took over the customer management side of things, whichc seems to have been a positive experience for this project.

Almost all of the issues were around miscommunication, in some way or another. The main solution to this sort of problem seemed to be a good project manager, who could make sure everyone was doing their job and communicating with everyone. It seems like it was a good.
As for the presentation stuff, it is a similar issue. Having someone who's role was specifically to make presentation material and be the main go-between guy with the customer seemed to really help. They seemed to say that having one such person, and thinking about such issues, from the very beginning rather than putting it off would have been/is very helpful.

The journals are WAY more useful to read than the milestones. The milestones helped give a sense as to what are expected in terms of writing out the milestones, and the need for a concrete description of them. Other than that, the journals foreshadow a lot of the problems that we will more than likely encounter, and we'll be smart to learn as much as we can from them.

Coding parties sounds like a really fun idea - even if they become more of a decompression than a fit of coding. At the very least, it encourages stronger group interaction. It seems that to evade people from doing all of their coding at such group meetings, maybe they should be scheduled right after milestones are due to get a fresh start on the next ones.

These thoughts are still somewhat scattered, and I don't know if I wrote down everything I wanted to. Next time I ought to make a list of things as I think them up - planning and that sort. I may come back to edit this when more comes to mind.

I also wish I had the time to review more years - very informative. Reading the journals for a whole year takes quite a bit of time, whew!

Also, was there a warm-up project last year or in the past? If not, then having read all of that really makes me appreciate some of the things that we're accomplishing through the warm-up project right now, not including the actual project itself.

I think it would be VERY useful to have some sort of IRC chat so that class members can communicate and ask questions even when not in the Symonds Lab. It works wonderfully in Comp 314, and I think it can work even better here. I think the most important reason why we need this is that in a real-life company, you always know people are available 8-5 and in the same office, but here that is virtually impossible, so having some sort of easy, instant communication can be very useful.


Off of that, one of the best pieces of advice from last year's journal was Hy's epiphany that this class is more like a company than an actual class and should be treated like so. It helps me to think about the project more like a corporate project that needs to go into production than like a class project that simply "needs to work".


Finally, I think it's a great idea to have people build a proof of concept to show to the group first so they can get lots of suggestions before they sit down and try to build it all in one sitting. Even though it may take more time, it's very useful to build stuff in steps.

Overall, most of the journals were quite informative and well written.

There are a lot of things we can learn from last year's efforts. Probably one of the most relevant issues at the moment is collaborating with others instead of struggling alone. Up until now my work paradigm has been solo effort, so I know it will take a lot of effort on my part to work effectively with others.

While reading through these journals, I found myself saying 'I know a lot of this stuff, I've worked with people before.' But it's a lot easier to say that than actually think about it while I'm working, and try to prevent the same mistakes people before me have made. Also, I feel like these journals are a lot of information to digest at once - it seems like they might be better as something to go back and look to see "what they did in this situation".

Last year's group seemed to have a large number of strong-willed people in it, which led to quite a bit of conflict and mule-like stubbornness. I don't know if it's simply that we're in the beginning of our project and these attitudes are still latent, but so far our group seems very civil and cooperative, almost to the point of being passive for some people. I think I'd like to work in a group like this much more; I hope it stays this way.

I think the advice from previous classes is very helpful - I only worry that like most of them say, we won't follow it. The problem, really, is that these problems keep cropping up because it's human nature. It requires a lot of self-discipline to do what is necessary to avoid them, effort that no one is willing to spend unless we know that it is necessary. And like a lot of things, we only truly believe in - rather than simply understand - the necessity if the consequences have already once befallen us. I think that's the point of the Warm-Up project. Hopefully by the end of Monday's class, we will be willing to take the advice of ex-410er's to heart not just in spirit, but in action as well.