Here is some advice on good team work and programming, some of it
collected from previous software capstone classes.
Working in teams is hard. If you're very lucky,
someone on your team will be a gifted facilitator - someone who spends
time (and is good at) making sure everyone is getting along and making
progress, and that the team as a whole is communicating. A
facilitator is an extremely valuable team role; you're sure to have
people who can code, but it's not certain who, if anyone, will be able
to assume any kind of leadership position.
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.
- 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.
- 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
- 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.