I wrote this up as a Lessons Learned after completing SPIDER for CS 460.

Well, it's over with. What to take away from the project?

1. I'm not allowed to come up with class names :) Mixed case descriptive class names are a pain to type.
2. Concentrate on the risky areas early and often. Leaving the tough stuff until last means lots of late nights and grumpy days.
3. Flexibility makes or breaks a team. When one member slacks, the rest have to be there, pulling harder. Everyone has bad times, a team must get through those times without finger pointing and hard feelings.
4. Prototype.
5. Prototype early.
6. Prototype often.
7. Have I mentioned prototypes yet?
8. Think about debugging and error checking early. Debugging scaffolding is easier to construct when there isn't a lot of program structure to get in the way.
9. Learn how to spell "debugging". There is a 'g' on the end of the word, no matter how often my typing fingers want to discard it.
10. Spend the extra time making good class designs. The detail level is probably too low, no matter how much I put in.
11. Use some type of version control system.
12. Keep a backup copy of the work in progress someplace else.
13. Set up a common vocabulary for the project. Having the entire team speaking a common jargon can make things much smoother. The common jargon makes it easier to keep ideas consistent.
14. If one team member has an objection, everybody should listen. Too often one person sees something that the rest of the group is missing.
15. Before fighting for something, ask yourself if it's really worth the energy. Don't defend something just to defend it.
16. When you think you understand something, explain it to the person who taught it to you. You'll probably soon find out that you didn't understand nearly as much as you thought.
17. If something starts looking like a Swiss Army Knife, ask yourself if there isn't an easier, less complex way to do those tasks. (This function slices, dices, juliennes, and allocates computer memory, all for the low, LOW, LOW price of only $19.95 plus $8.95 shipping and handling).
18. Keep focused on the goal. Remember that a computer project is something that you do, it isn't who you are.
19. Get away from the project every now and then. You'll feel guilty for abandoning the project, but the time away will give you a chance to relax, to think about the project in new ways without really thinking about it, and to refresh yourself. Burning out is a BAD thing.
20. Keep a sense of humor. Laughter will get you and your team through the project much better than any amount of grumping and grumbling.
21. Meet face-to-face with your team often enough to keep track of where the project is going, but at the same time not so often that you prevent the project from going anywhere.
22. Do something useful at the meetings. There is plenty of time to chit-chat when there isn't a project to work on.
23. If nothing is getting accomplished at a meeting, the meeting is over.
24. Remember that you don't live in a vacuum. Pay attention to the parts of your life that aren't part of the project.
25. Try to have less than 20 things I learned in a post mortem. :) :)
26. Log down errors that you commonly make. You might find yourself making those mistakes less often after a while.
27. A faster processor and more memory is always better.
28. If a project is going to be divided up, make sure that one part is to track the big picture.
29. Divide functionality up into lots of functions. It is much easier to merge several functions into one than it is to split one function apart into several smaller functions.
30. There is no such thing as a team of one.
31. At the end of the day, remember that life isn't a goal, it's a journey. Enjoy the trip, because eventually the ride will end.