CSE 490DF 04wi team work

Here is some advice on good team work and programming, some of it collected from previous software capstone classes.

Team work

It's common for people to become frustrated with each other. The first four times you think to yourself "Harry is lame" the problem most likely lies with you, not Harry. Whatever you're contributing is going to be most valuable if it's surrounded by things other people have contributed, and so it's to your benefit to make sure Harry is contributing. As a team, you should find something for each person to do that (a) they want to do, and (b) they can do. Everyone has skills the others don't.

Make your best attempt to help Harry contribute. When you've done that four times and you're still thinking he's lame, there's a real problem. It may be that some other person on your team needs to handle it, or it may be that the course staff have to handle it. Coming to the staff is not turning someone in, it's just letting us know that there's some kind of problem. We promise to use our own highly fallible judgement coming to any conclusion about what the problem might be.

It is critical that you are sensitive to the role of ownership in team work. There is no such thing as cheating in this class - help each other out. An individual team owns the final product. It is crucial that everyone be allowed to contribute to what that product becomes. No one is going to work hard on anything that they have no influence on (and you can't afford as a team to have anyone not working). Finally, each person on the team needs to have some identifiable role that they own, and that is their responsibility. When you're done, everyone should have made contributions they're proud of.

Programming Robots

Keep it Simple. There is no way you will be able to solve all the problems at once. Develop and solve simplified versions of your problem first. Once you have all the simple pieces integrated, you can start to work on the more difficult instances of the problem.
Simulation. As you will find out, working on the real robots is very time consuming and the code is difficult to debug on the robots. Using the simulator can safe a lot of time, especially in the early phases of the project. However, no simulator is perfect and it is crucial to test your code on the robot, once it is debugged.
Logs and Visual Output. Things happen very quickly, once your code runs on the real robot. This makes it extremely hard to understand what is going on. Displaying the state of the system using the robot's LEDs and with graphical output can be very helpful in such situations. Furthermore, write all important information into log files so that you are able to replay situations.

General Advice

Communication is the key element to success. Your group needs to find a way to communicate effectively as soon as possible. There is no substitute for face-to-face communication -- you are strongly encouraged to establish a schedule where you are (almost) all together in one room for a few hours of development time multiple times per week.

Try to make some progress every day. You have 9.5 weeks. That's not much time to program a robot, but it's too long a time to try to work on this project as you might on a 3-week project. Slow-and-steady will beat bursts of activity in the long run.
Do it once. You don't have enough time to build anything multiple times. Try to get it right the first time. This means you have to design and test well enough that a component actually works, and does the right thing, the first time. You'll make much more progress slowly building an assemblege of reliable, appropriate components than you will quickly building a morass.
Set frequent milestones. A schedule (milestones) does two things for you. First, it's hard to work to a vague goal - the more concrete the goal, the easier it is to be motivated. Second, you can't know when you're behind, or how to adjust, if you don't have a schedule.
Prioritize. It's easy to let yourself work on the coolest thing, rather than the most important. Try to keep that to a minimum. Also, it's easy to work on some one thing past the point where it remains the highest priority item. Avoid that as well.
Integrate early. Integration, getting all the components to work together, is the critical milestone. Pre-integration you'll be working on independent components that eventually must work together to achieve a task. No matter how smart you are, it is not possible to predict all problems that might come up. The earlier you integrate and face these problems, the better your chances of succeeding.
Additionally, pre-integration you don't have a working robot. Post-integration, you do, even if it's not (yet) doing a great job. Once you've achieved integration, development becomes a lot easier. You'll basically be improving the behavior of the robot, piece by piece. It's much simpler to work independently, and so to get a lot more done by having everyone working at full capacity.
Corollary: Minimize your schedule risk by integrating early. You can't be sure how far in your design you'll actually get in 9.5 weeks. Schedule in a way that you have something presentable early, then work to improve it as much as you can.
Don't do this: The most ineffective schedule, proven by history, is to (a) not attack the hard parts (the risks) early, and (b) not test components as you build them, so that (c) you end up spending 7 weeks repeatedly debugging the things you didn't do right the first 3 weeks.
If you don't know it's broke, don't fix it. It's pretty common for teams to invest time early on addressing imagined performance problems with some complicated design. Don't. Your guesses about what will be and what won't be a performance issue are probably wrong, and in any case you don't have time work on imagined problems when there are so many actual ones floating around.