Meeting Time

MWF 1:15-2:30pm in LSRC room D106

Class attendance is required as class time will often involve participatory exercises, code reviews, or team meetings. You will also be expected to do a significant amount of reading, coding, and debugging outside of class time.

Course Staff

	Professor: Robert C. Duvall LSRC room D228 660-6567 Office Hours: TBA Drop-in policy: Feel free to come in whenever my office door is open; you may also make an appointment via email.
	Graduate TA: Bing Xie North room 002 660-4002 Drop-in policy: Available outside of hours by appointment only.
	Undergraduate TAs TBA

Email is the best way to contact the course staff if you have a personal concern. When using email, please put CompSci 108 at the start of your subject line to help ensure that your email gets past our spam filters and is delivered correctly. If you send us an email and do not get a response within 24 hours, we probably did not receive it. In general, you should only email us about administrative aspects of the course; questions about course content are better made using the course Bulletin Board since it is seen by more people.

Books

Most of the readings assigned during the semester will be excerpts from books or online articles. However, many students also like to use a reference book about advanced programming topics, so the books listed below are optional. There is lots of information available online, but the books below are rather complete in their coverage. If you choose to buy any of these books online, please click on this link to buy from Amazon so that your purchase contributes to undergraduate Computer Science Research at Duke.

Java How To Program by Deitel and Deitel Core Java by C. Horstmann and G. Cornell Thinking in Java by B. Eckel (an online version of the previous edition is available)

In general you should do the readings in order to be prepared to ask and answer questions in class. Reading quizzes may be given at the beginning of class to ensure that you have looked at material before it is discussed. On days where no quiz is given, time will be given at the beginning of lecture for you to ask questions about the reading. The majority of class time will be an extension of the reading, not a summary.

Topics

The following topics will be covered during the semester.

• Advanced Java: Generics, Reflection, GUI Programming
• Program Design: Principles, Patterns, Architectures, Frameworks
• Tools: Debugging, Unit Testing, Version Control
• Working in Teams: Agile Processes focusing on Communication and Cooperation

The exact order and details of these topics will be given on the course Calendar, which is subject to change during the semester based on the pace needed.

Grading

This course is about the creation of software in teams, thus it is much more than simply a programming course. Thus to receive a passing grade, you must demonstrate both that you have completed some significant programming and that you have been a successful part of a team. This emphasis is reflected in the grading weights below that give equal weight to the programming assignments and "soft-skills" needed to survive as a software developer.

25%	Engagement: participation in class and on-line discussions, in your team-work, and in your in-class presentations
25%	Skills: progress improving in coding, designing, and project planning and management
50%	Assignments: refactoring, team, and final project grades

To help track your improvement during the semester and to keep you informed of your progress, you will be required to meet weekly with one of the course staff (assigned to you at the beginning of the semester) to discuss your work done during the week.

The grading for this course is more like an art course than a standard CompSci course. In truth, when grading large software projects, I often feel more like a humanities professor grading essays than I do a Computer Science professor testing whether a program simply works or not. Grades are determined by a combination of criteria that, to you, may seem to border on pure subjectivity. As much as possible I will try to produce an exact definition of the criteria I use when grading your body of work. Each software project will be graded in the following categories (as they pertain to the assignment):

30%	Design: how well designed is the project?
20%	Quality: how robust is the project? how well tested?
20%	Completeness: how well does the project work?
15%	Craftsmanship: how clean and readable is the code?
15%	Documentation: how well is the design documented and justified?

In general, to earn an A on any assignment you must go beyond what is expected. Meeting all requirements is worth only a B+. Meeting all requirements superbly can earn an A-. Doing more than is required, or doing astonishingly good work, is the only way to earn an A. With that in mind, each category above will be graded according to the following scale; roughly 0 is a F, 1 is a D, 2 is a C, 3 is a B, 4 is an A-/B+, 5 is an A. Grades of 3+, 4+, etc. are possible. Grades mean roughly the following:

5	Excellent: outstanding, shows insight beyond straight forward application of course concepts
4	Good: complete
3	Satisfactory: reasonable, but some room for improvement
2	Poor: okay, but needs significant improvement
1	Minimal: attempted, shows only basic application of course concepts
0	Absent: no evidence of work done

Note that your program's design and robustness each count at least as much as its functionality. This implies that a solid, working sub-set of the complete program, with a design that clearly supports easily adding the remaining functionality, will receive a higher grade than a completely functional program that was hacked together at the last minute and was not obviously tested. Unlike in other Computer Science courses where the program's functionality is primary, this course focuses on program design. In fact, the project requirements are usually chosen to highlight a specific set of design ideas. Simply implementing all of the requirements without evidence you have thought about how to design them for future changes will result in a low overall grade. On the other hand, small bugs in some of the requirements will be tolerated if the design is extremely well done.

Only one summary grade will be given for each programming project. Thus your individual grade depends not only on your programming skills but on your ability to work with others. More credit will be given to programs that have minimal, but collaborative, functionality than to projects that have one piece working perfectly, but do not represent the integrated efforts of the team. In addition to the team's submission, each student must submit an individual project analysis after submitting the final version of the project. This analysis will not affect the team grade, but may impact your individual grade. For example, if the team project fails, despite your best efforts, but you write a good, concrete, and detailed analysis of why it failed you may receive a D on the project, but an A on the analysis.

In general, teams will be chosen for you although there may be some instances where teams will be based on your recommendations. This means that your team may not be an ideal mix of compatible personalities. As a team, it is your responsibility to identify problems as soon as possible and still plan to deliver a working program. You will be asked to assess your fellow student's participation in the team in such a way that it factors into their final grade.

A final project will be assigned instead of a final exam. This final project must be completed and handed in before the course's scheduled exam time. This project will be presented in an open session, attended by your classmates, graduate students, and other faculty members during the scheduled exam period. Additionally, you may be assigned to meet with the professor as a group to demo your project and discuss its details. Plan on this demo taking approximately an hour --- everyone in the group must attend this demo.

No Late Submissions

This class moves at a demanding pace and getting even a few days behind can be hard to recover from since, like a domino effect, each tardiness tends to propagate through the following assignments. Late work also makes extra work for the staff since we try to get things graded as soon as possible. Thus all projects must be turned in on time. If, for some reason, you (or your group) cannot meet a specific deadline you should hand in your best effort by the deadline. You should then to make sure to write a detailed project analysis, including what you would have done if you had more time and how you will avoid such problems in the future.

This may seem overly harsh, but it is important that you do not get behind in this course, its pace is too fast. Additionally, it allows us to give you feedback as quickly as possible. The secret to successfully surviving this course is to start early and work steadily; it is not possible to cram or skim in Computer Science courses. If you are having trouble, be sure to see one of the course staff as far before the due date as possible. Do not give up, ask for help.

Individual extensions will be granted only for medical reasons (see the Short-term Illness Notification policy) or other circumstances beyond your control that must be presented with an official Dean's excuse. Extensions will not be granted after an assignment is due, you must request an extension well before an assignment is due.

Submitting Projects

For each project you develop for this course, your team should submit one version of all project materials that represent the team's effort electronically, using the directions available here, by the end of the day (i.e., 11:59:59pm) on the due date given. Your team is responsible for ensuring that all files are turned in on time. Your team may submit its project electronically as many times as necessary, but only the files included in the last submission will be graded. Thus, you should always submit all your project files --- even if they have not changed since a previous submission.

Submit only code (.java), text (.txt, .dat, or .xml), HTML (.htm, .html, or .css), PDF, image (gif, jpeg, or png) or sound (.au, .mp3, or .wav) files. You are free to use any programming environment available to complete your work, however, you are responsible for converting it into one of the standard formats listed above (most current programs can save or print files to a variety of alternate formats). All programs must use only standard code that runs on any platform (i.e., Windows, Mac OS X, and Linux); no platform specific code will be accepted.

In addition to the project's source code, you are expected to several supporting

Collaboration Policy

In accordance with the Duke Community Standard, we encourage proper collaboration, in which all parties equally participate, on programming projects and classwork. Quizzes and Exams taken online or in-class must be your own work; you should not collaborate on them at all. Studying together is always encouraged, especially when preparing for quizzes or exams. At other times you may be assigned to work in a group, in which there will be only one submission for the entire group that represents your collective effort.

You are responsible for understanding all work you turn in. For any given assignment, an interview may be included as part of the graded work. During the interview, you may be asked to explain the problem solving process and individual lines of code not given as part of the assignment. Turning in code that you cannot explain is considered cheating.

You may consult with the course staff about any aspect of the course. On programming projects and classwork you may consult with other students only in a general way, e.g., about debugging, programming concepts, or questions about wording on the assignment. You cannot actively work with someone else unless the assignment specifically grants permission for you to do so. It is never acceptable to directly show one another your program code or write one program among a group and submit multiple copies. Finally, it is unacceptable to search for direct answers to problems on the Internet.

Consult means you can discuss programs in a general way before writing code and get help with debugging your program, but you must write your own code and do your own thinking about the problem. For each assignment you are expected to include a list of the people with whom you have consulted (including any other students and course staff) in the README file you submit with the assignment. You should also cite any resources other than class materials you use (e.g. webpages, notes from other courses at other universities, etc.). This file is required and failure to provide it will result in rejection of the assignment as complete.

If you are not sure what the collaboration policy is for a given assignment, please ask!

Computing Requirements

All computing projects will use Java 5 or above, the Eclipse programming environment, and the Duke Ambient plug-in for downloading and submitting projects. More information about installing this software is available here.

Online Course Information

Web Page
Many of the materials for this course, including the syllabus, class notes, reading assignments, homeworks, and other resources, will be available through the course web page at http://www.cs.duke.edu/courses/spring10/cps108/

Bulletin Board
You should regularly read and contribute to the course bulletin board as it is a useful place for posting questions that are likely to be of interest to the rest of the class. You are encouraged to post responses to questions as well as ask them. The bulletin board will be monitored regularly and responses posted to questions that have not previously been answered. Before posting a question, please make sure that you have read all previous messages and that your question has not yet been discussed.

Finally, please check your email regularly, as important course announcements may be sent via email.