At the end of term, three knowledgeable outside programmers chosen from local software industries will evaluate the system as a whole with respect to our three goals: flexibility (how easy is it to change?), robustness (how likely is it to be bug-free?), and clarity (how easy is it to understand?).

Each person will produce a web document describing what they have done and how they have contributed to the project's flexibility, robustness, and clarity. Each team will pool all such documents and produce a single web document describing the team's work, and ascribing credit for each part of it to the appropriate team members. In the interests of accuracy and minimization of argument, each team should add to this document weekly, rather than waiting until the end of term to argue over who did what.

Evaluations will be divided into three equal parts based on:

(1) The outside programmer's evaluation of the project we finish by the end of term. This includes not just working code but also documentation. Good documentation is as important as good code.

(2) Your team's evaluation of you.

(3) My evaluation of you individually. This will be based on your performance on the assignments, your contributions to your team, and your team's contributions to the project. I will rely heavily on your team's document of each teammate's accomplishments, looking for signs of:

Personal Initiative: independently solving tough design problems, coming up with better ways to do things, and demonstrating willingness to work hard.
Coding Strength: producing clear, flexible, robust, and well-documented code.
Coding Volume: producing quantities of good code and documentation.

Excellent Ways To Lose Points

Teamwork: Producing poor team documents, frequently breaking builds, continuously failing smoke tests, non-adherence to design documents, poor code, and clear evidence of inattention to work.

Coding: Producing buggy code, non-robust code, failing to use assertions, not checking input values, poor use of exception-handling, poor choice of variable, class, method, and package names, poor use of named class constants, interfaces, and abstract classes, and lines longer than 80 characters.

Other ways to lose points like bad coding style, inconsistent coding style, no newlines around methods, no spaces around operators, inconsistent indentation, and so on, might be made to go away with a pretty-printing tool. (See the support tools page.)

Documentation: Producing poor or no in-line documentation, poor description (or no description) of class behavior, poor CRCs for each class, and poor package-level documentation.

Writing: Failing to start with motivational background material, not including overview material, poorly stating ideas, poorly organizing ideas, and using poor sentence structure and bad paragraphing.

English: Using non-grammatical English, misspellings, and incorrect punctuation for any part of the project (code or documentation).

Webpages: Bad webdesign (especially backgrounds that make foreground text hard to read), stateless animated gifs, huge web bandwidth requirements, bad spacing, and poor layout.
 
Excellent Ways To Gain Points

Initiators: The single best way to gain extra points is to demonstrate initiative and get the job done, whatever it takes. (Also, if you're interested in making it into the Above and Beyond category, this is what it takes.)

Leaders: Extra points will go to team leaders who help coordinate their team's efforts and help motivate their team to excel.

Architects: Extra points will go to team members representing their team on the architecture team since they will have extra work independent of their work with their own team.

Documenters: Extra points will go to team documenters if a team wishes to delegate documentation duties to one teammate and that person accepts.

Supporters: Extra points will go to anyone implementing good support tools, especially those that can be used by everyone in the project (pretty printers, documentation aids, code check-in controllers, build managers, smoke test integrators, and so on). Such tools may initially be in other languages (notably prototyping languages like Perl, Python, and M4) but must eventually be translated to Java for maximum portability and robustness. To be of the greatest use, however, such tools will have to be developed as soon as possible and put in place before the main coding effort begins.

Designers: Extra points will go to well-written and well-designed webpages.