Welcome to ENGR2510, more colloquially known as Software Design, and more realistically thought of as Software Design of Modern Complex Systems in Java But That Takes Too Long to Say. We'll call it SD from now on. In a nutshell, the idea of the course is to teach you how to think about programming in the context of an interacting system of independent agents. We'll be using Java as our programming language, but the concepts you learn, such as abstraction, interfaces, multithreading, communication, and good coding style should stand you in good stead no matter what programming language you use.
This handout and all other course information can be found on the web at http://www.cs101.org/courses/fall05/
This year, SD will be taught by Mike Wessler, a visiting lecturer with deep twisty ties to this course from the distant, misty past.
All right, I'll admit it. I was once Lynn Stein's graduate student at MIT, where I helped teach an early version of CS101 way back in 1999. After being a tenured ("ten-year'd"... get it?) graduate student, I'm now working in the real world, programming in Java every day. In Real Life, I work at Sun Microsystems Laboratories up in Burlington MA, but I'll be here at Olin three times a week for class.
I do not currently have specific office hours posted, but I do plan to hang around after class on Mondays and Thursdays. In addition, you should feel free to schedule an appointment with me at other times. You should be able to reach me mike.wessler at olin.edu.
Katie Rivard is an Olin senior who's nearly as old a hand at this course as Mike, having taken it in her first year and TA'd in her sophomore year. She's back once again for more punishment this year. Please remember that Katie is an Olin student, and will occasionally have to attend to her own schoolwork, but she should be a very valuable resource to help with yours in this class.
The text for this course is the still-as-yet-unfinished Interactive Programming In Java (IPIJ). You'll find tons of "Image not yet drawn" pictures in the text, some of Lynn's comments to herself scattered about, and some entire sections that are obsolete, but between the rough edges is a very fine book that follows the course pretty well, for obvious reasons. If you'd like to geek out, you can report bugs on the book at the CS101 Bugzilla site.
For reference materials about Java, you should probably try the official Java API from Sun. There's actually a wealth of great tutorials and other material about Java at Sun. Unfortunately, Sun's site is almost impossible to navigate, and this is me saying this (I work there). I suggest looking at the tutorial trails if you want to learn how to use any set of libraries we don't cover in class.
This course requires that each student bring their laptop to class and to lab. Please be smart about laptop use. Don't succumb to becoming an IM and e-mail junkie during class. We don't intend to turn into laptop police, but I've been known to spring surprise questions on people who look like they're drifting off into their own world. You may think you can multi-task (it's why you're here), but it's amazing how much more you retain when you give something your full attention.
Lectures run on Logical Mondays and Thursdays from 10:00 to 11:50am in AC318. Note that some Logical Mondays and Thursdays don't fall on Actual Mondays and Thursdays. See the syllabus for more details and for lecture topics. Don't panic: we'll have a break in the middle of class so you don't get sore from sitting for two full hours.
Every Logical Wednesday, there is a lab from 4:00 to 6:50pm. Labs are mandatory, and should be treated just like class. The lab assignments are designed so that you should be able to do all your programming work during lab hours. This means that you should figure out what you'll be programming before you come to lab.
You should expect to spend about six hours per week outside of class preparing for the labs and completing the lab writeups. We will be asking for feedback periodically to determine if people are spending too much or too little time on homework, so we can adjust the course load accordingly. If you find yourself struggling with the homework please let me or Katie know so we can give you extra help. If you find you're getting bored, please also let us know, so that we can help you get more out of the course. We don't want experienced programmers to get lazy at the beginning of the course only to find themselves swamped at the end.
Speaking of being swamped at the end, you should know now that the last month of the class is devoted to you, in teams of two to four, dreaming up, designing, implementing, and documenting(!) a large networked software project. If you plan well and use your time efficiently, this shouldn't impact your weekly load. If you tend to procrastinate, we sympathize, but you'll get incredibly stressed as the deadline draws near. Remember that bugs succumb best to sleep.
You are expected to be present in each lecture and lab. If you can't come to one of the lectures for some reason, including religious holidays or scheduled events, make sure that you get class notes from someone else. Some of the material covered in class won't show up anywhere else. If you can't make it to lab, you must arrange a rescheduling as far in advance as possible. The only exceptions to this policy (i.e., last-minute or after-the-fact rescheduling) will be in cases of significant and unanticipatable emergency. In these cases, we request a note from the Medical Department or the Dean's Office.
During the term, there will be seven or eight regular laboratories, two or three written assignments, and a final team project involving software development as well as oral and written presentations. In addition, there may be a few quizzes given throughout the year. The quizes (if we give them) will be primarily for diagnostics, and will count no more than 10% toward your grade.
Each laboratory will have three parts: pre-lab preparation and written problems, in-lab programming work, and post-lab writeup. You should expect to spend up to three hours on the assignment outside of the scheduled lab time, but you should limit your programming time to the three hours of lab. To keep this limit, you must complete the entire pre-lab work before you come to lab. If you find yourself spending too much time on the assigments, please see me so you can get some extra help.
We encourage and expect you to work together to understand the labs for the pre-lab work. You should initially read the entire lab assignment and try any "finger exercises" yourself, but do talk with other students in the class or even the course staff about any parts that confuse you. During the lab itself, you will be working on your own code for most of the labs, but we strongly encourage you to consult with each other if you have problems. Nothing solves bugs like an extra pair of eyes. The final lab write-up should always be your own, and should include the names of the people you collaborated with during the other parts of the lab.
No, there will not be a final exam. The team project and oral presentations will be a comprehensive test of your understanding of the course material.
Your grade in the course will be a weighted mixture of the laboratories, written assignments, and final project, together with an assessment of your understanding of the course materials made by the staff in lab and through your class participation. Your final project grade will reflect both the team-produced product and your personal contribution to it.
If none of the three descriptions above fits you at the end of the course, there are two possibilities:
Late work will not be accepted and may be treated as missing work. There is a new lab every week, and we will be using lessons that you learn in lab in classes that follow shortly after. It is always better to turn an incomplete lab in on time than it is to attempt to finish it and turn it in late.
This section details the general course collaboration policy. Certain assignments require different kinds of, or restrictions on, collaboration. When the collaboration policy differs from that described here, it will be specified in the laboratory assignment.
We encourage you to work together on the pre-lab exercises. They are designed for working in small groups, allowing you to help each other learn and to balance your knowledge and strengths. Note that collaboration extends to discussion and problem-solving, but not to writeups. We expect that any written work you turn in will be your own, though it may reflect joint preparation.
Laboratory work is a more complex topic. It is often useful to discuss your program with peers or with course staff, and we strongly encourage this. It is particularly useful to do so as a means of debugging your program. Reading code written by others and having others critique your code are good ways to improve your programming style. However, it is of no benefit to you or to anyone else to have someone else actually do your laboratory work. We expect that the default assumption (i.e., unless specified otherwise) is that laboratory assignments are your own work, but may reflect input from others just as an essay edited by friends might. You should be the one who wrote the code you turn in.
Some labs, and the final project, will involve more explicit collaboration. In those cases, we will explicitly specify ways in which labs can be broken up, so that each person writes code but no one person writes the whole program, or indicate explicitly that a particular lab or portion of the lab may be programmed together, as a team. Even in this case, it is important that each team member have an opportunity to independently compose some code. Since the pre-lab will generally involve designing the code that you are going to write, it is best to also allocate responsibility for pieces of the code to members of the team at that time.
In each piece of work that you turn in, you must specify everyone with whom you have collaborated and each person's role in the collaboration (e.g., pre-lab, post-lab discussion and analysis, in-lab coding (specify which pieces or how responsibility was distributed), debugging, or advice). Failure to specify such collaboration will be interpreted as a statement that you have not collaborated with others in your work. While this is acceptable under course policy, it is probably ill-advised. (Really. We want you to work together and to learn from each other!)
Examinations are diagnostic in nature and as a consequence should represent independent work.
In all cases, wholesale copying of the work of others is entirely unacceptable.