Course Mechanics

Summary: Explains course activities, policies, and recommendations.

Contents:

Note: Even if you've taken a course with me before, please read this syllabus carefully. Because of the nature of this course, I've chosen some activities and policies that are quite different from my usual approaches.


Learning activities

This class meets twice per week on Tuesday and Thursday from 2:15 to 4:05 p.m. Although this is nominally a lecture class, I plan to lecture as little as possible.

A major requirement of this course is to undertake a significant team software development project: specifically, a Web application.

Before Fall Break, our focus will be on preparing for the project. I've set what I believe to be an ambitious schedule for plowing through this material. However, the assignments will be relatively small scale and focused on developing skills rather than assessment. (Please don't feel lost--come talk with me if you feel you need more feedback than you are getting.)

During this time, I expect you will need to spend a total of 8-12 hours per week outside of class to do readings and exercises. Don't expect to do the readings between 9 and 10 a.m. the day of class!

After Fall Break, you will embark on your project.

During this time, I expect you'll spend less than three hours per week reading and the remainder of your time (roughly 8-10 hours per week) on the project, in addition to the time you'll spend in class.

Particular activities are discussed in more detail below.

Project

Because of its scale and importance, the project gets its own section of the course Web site.

Technical exercises

The Ruby on Rails 3 Tutorial is meant to be hands-on. To learn the concepts and skills, you are expected to follow along with the code presented in the text and to do the end-of-chapter exercises, as well as any additional exercises that I pose. In addition to the Rails Tutorial, we'll do hands-on work with database design and SQL.

As we work through these technical exercises during the first half of the semester, you will have class time for technical work: part of class on Tuesday and most or all of class on Thursday. I will expect you to work in pairs; I will require the pairs to mix up at least once and possibly several times. Any students who have prior experience with Ruby, Rails, or databases will be expected to spend some time mentoring their classmates, because that's the professional thing to do.

You will commit most of your technical work to GitHub, a public revision control repository. When you switch partners, you will also begin work on a new repository building on another pair's code. In order for the class to stay together, I expect you to complete most exercises before our next class meeting, and I will check on an occasional basis. (If you've done something you are especially proud of, let me know via email and I will make a point of looking at it.)

Some exercises will require pencil-and-paper work (e.g., the database design exercise). Other exercises will be more intensive (e.g., your extension of the Tutorial application) and you will have mroe time to complete them.

Although our "Tech Topics" after Fall Break may involve programming exercises, you will not be assessed on these exercises and you need not complete them after class. They are for your professional development and/or to learn skills for your project; make of them what you will.

Reading responses and class discussions

To prepare for discussions of Extreme Programming and some other topics, I will pose questions for you to reflect upon as you read, and then respond to in writing. These questions will usually require a prose response--a sentence or a paragraph--but sometimes snippets of code. When assigned, reading responses will be due via email by 10 a.m. on the day of class. This is intended to give me plenty of time to adapt my lesson plan to the content of your responses.

You will discuss the readings; my role should be to facilitate your discussion. I do not intend to lecture over the readings. But, I've learned (painfully) that it is all too easy to unintentionally fall into lecture mode. If you catch me lecturing, please stop me!

You can expect to have a reading response due every Tuesday during the first half of the semester, and occasionally on other days.

Oral examination

I struggled to figure out how to evaluate students' individual learning in a way that fits the learning goals for this course. Written exams are rare in the software development workplace (although sometimes used for certification).

To make individual assessment relevant to our goal of developing professionalism, each student will be examined orally in a format similar to the technical component of a job interview. Exam questions may concern programming in Ruby, Ruby on Rails, database design, SQL, Extreme Programming, development tools used in the class, and/or your experiences with the project.

Individual examinations will be scheduled for Finals Week. We will further discuss the format and scheduling of oral examinations at some point during the final two weeks of class.


Policies

Academic Honesty

I expect you to follow the highest principles of academic honesty. Among other things, this means that any work you turn in should be your own or should have the work of others clearly documented.

In particular, I encourage you not to reinvent the wheel if your project encounters a technical problem that has already been solved, but rather to use code that has been shared for the purpose of education and reuse: from our textbook or other technical/tutorial books, from Web-based tutorials, or from open-source projects (being aware of the project license). If you use code verbatim from source such as these, you should cite the source of that code in a comment or README file and/or preserve any copyright notices that are distributed with the code.

You should never give away answers to exercises or examinations. You may, however, work together in developing solutions for most exercises. You are strongly encouraged to use each other as resources in your technical work; in the workplace, colleagues will often be one of your most important sources of advice and information.When you explicitly work as part of a group or team, you need not identify the work of each individual, unless I specify otherwise.

Accomodations

If you have a disability that requires accommodations, please let me know early in the semester so that we can work together to find accommodations that meet your learning needs. You will also need to provide documentation of your disability to the Academic Advising Office, located on the third floor of the Rosenfield Center (x3701). See the Student Affairs page on Academic Accomodation for more information.

Attendance

In this course, I won't take attendance and there will not be an explicit policy mapping attendance to grades. However, professionalism demands that you attend class consistently and participate in both discussions and technical work. Make sure your classmates know you by the time we arrange project teams. Even if you already know the material, you should support your classmates, who may later become your teammates.  Don't let your teammates or your pair programming partners down. If I don't see you for several classes in a row, we will need to talk about whether it is appropriate for you to continue in the course.

That said, I do care about you, and if you miss class I would appreciate a note to let me know what happened. Touch base with your classmates, catch up on the work you missed, and come see me if you have further questions. If I see that you have missed several classes, I will be in touch with you.

Deadlines

Reading responses are due by 10 a.m. the day of class in order to give me time to prepare a lesson plan that takes your responses into account. Unless another due date is given, technical exercises should be completed by the next class period after we work on them in class.

Because the first half of the semester will have a rapid pace and the second half of the semester will focus on the team project, all work is due when it is due. There is no policy for accepting late work. If there are exceptional circumstances, talk to me.

Absolute deadline: All work must be turned in by Friday, December 21 at 5 p.m.

Getting help

I am available to mentor and advise you on technical issues, software development process, pair/team dynamics, and other matters related to the course. We can meet one-on-one or in a group. When necessary, we can discuss issues that concern your whole team during class time. If team meetings aren't already on the agenda, please let me know in advance via email that you want to make time for this.

See my contact information to learn how to make an appointment with me or when to drop in.

Grading

Because of the goal of professional development, I see my role in this class as more of an adviser, mentor, and facilitator than as an instructor. However, it is also part of my duty to give you feedback on your progress and assign you a final grade for the course.

Exercises and reading responses will be graded on the following scale:

PLUS (105%) - Exhibits exceptional insight and/or craftsmanship.
CHECK (90%) - Meets the requirements of the assignment.
MINUS (75%) - Does not meet the requirements of the assignment.
ZERO (0%) - Not turned in.

We will develop rubrics for evaluating individual and group performance on the project as the project gets underway.

The following scheme will form a basis for final grades.

Reading responses
10%
Technical exercises
10%
Success of team project
30%
Individual contributions to project
30%
Oral examination
20%

I do not believe in grading on a curve; I would be thrilled to give you all As.


Janet Davis (davisjan@cs.grinnell.edu)

Created August 25, 2012
Last revised August 26, 2012