CS 312: Software Development
Class Sections:
A: Tuesday/Thursday, 9:45AM-11:00AM
B: Tuesday/Thursday, 11:15AM-12:30AM
All class meetings take place in 75 Shannon Street room 102
Instructor: Professor Laura Biester
You can call me Laura, Professor Laura, or Professor Biester, whichever you are more comfortable with
Email: lbiester@middlebury.edu
Office: 75 Shannon Street Room 214
Drop-In Hours:
Monday 2-3
Thursday 2-3
Friday 10-11
One-on-one Appointments: please email me to schedule a one-on-one meeting
Lunch Appointments: book here at least 24 hours in advance
purpose: casual discussion in the dining hall of topics related to CS but not directly related to the course, including but not limited to NLP research, the CS major, working in tech, and graduate school
Anonymous course feedback form
Course Description
From the course catalog: This course examines the process of developing larger-scale software systems. Laboratory assignments emphasize sound programming practices, tools that facilitate the development process, and teamwork.
Prerequisites
The prerequisites for this course are CS 200 and CS 201. If you are concerned about your preparation for this course, please come talk to me!
Learning Objectives
At the completion of the course you should be able to:
- Describe and employ modern methodologies for managing SW development
- Use tools and services that support those processes, such as version control, GitHub, continuous integration, etc.
- Describe and employ SW development principles, patterns and best-practices, such as test-driven development (TDD), DevOps, etc.
- Describe, evaluate and employ technologies for full stack web development and single page web applications (SPAs)
- Complete a large software development project as part of a team
Coursework
This semester we will be using a form of “specification” grading. Instead of using points to assess work, all assignments and exams will be evaluated as Satisfactory/Not Yet Satisfactory or with an EMRN rubric (Exemplary, Meets expectations, Revision needed, Not assessable). “Satisfactory” (S) or “Meets expectations” (M) is not synonymous with “minimally competent”, but instead an indication of a fully working program or having achieved the learning goals for that course element. There is no partial credit, instead you will receive feedback on your submission and, where possible, have one or more opportunities to resubmit an assignment or retake a similar exam problem based on that feedback. The only grade you will receive will be the final grade and it will be determined according to the bundles of specifications (listed below) you have satisfactorily achieved.
Why? A grade should reflect your demonstrated understanding of the material at the end of the course (and only that)1. Assessing your work is a necessary but imperfect proxy for assessing understanding. My goal and responsibility is to create the best structures possible for you to demonstrate your true understanding. And your corresponding responsibility is to do everything you can to make your work accurately reflect your true understanding.
Note that this is a new system for me and this course. I am committed to do whatever is needed to ensure you understand the expectations and processes and are equipped to achieve your desired definition of success. I welcome your feedback and am ready to change any aspects that are not working. My goal is for you to achieve a Satisfactory understanding of all material you choose to tackle.
This grading policy is adapted from Michael Linderman, who adapted some language from Jason Mittell, Robert Talbert and Brett Wortzman.
Programming Assignments: In the first half the semester you will complete (approximately) weekly programming assignments that help prepare you for the course project. Programming assignments are generally submitted via Gradescope and GitHub classroom. Programming assignments are evaluated on correctness and execution (see below, but generally “good style”). Each assignment will specify the criteria for “Meets expectations” and “Exemplary”, but the former will generally require a submission that passes most or all correctness tests. An exemplary submission will need to be well executed.
Well executed code works, but is also:
- Maintainable (design changes or improvements require a minimal number of changes to the code base)
- Clear (the code minimizes the cognitive burden on the maintainer)
- Minimizes unknown unknowns (the implementation is obvious to the maintainer)
- Sound (algorithmic/architectural choices are sound)
If your program does not successfully pass all of the automated tests or meet the execution goals prior to the due date, you can still obtain full credit. To do so, you must submit a meaningful attempt prior to the due date (or extended due date, see below). You can then resubmit your assignment (multiple times) prior to the late deadline. Note that this deadline is different for different assignments but is tied to the sequence of the course. For example, the programming assignments are designed to prepare you for the project. That only works if you complete them before the project is really underway (e.g., the 6-7 week of the semester).
When you are ready for a resubmission to be evaluated, please send the instructors an e-mail to that effect. Resubmissions will not be evaluated until you notify me (since I won’t know if your code is ready). A meaningful attempt is generally characterized by passing some but not all of the automated tests. The ability to resubmit recognizes that learning is an iterative process that doesn’t always happen exactly on schedule. However, making an attempt by the due date ensures you are regularly practicing and solidifying what you are learning (especially while it is fresh!).
Practical exercises: Throughout the semester, there will be a collection of in-class programming exercises where you will work through step-by-step examples. These will typically be completed in class, but occasionally you may be required to complete them outside of class. Similar to your programming assignments, the practicals will have a suggested due date and final due date by which any revisions must be completed. The practicals will be evaluated as Satisfactory/Not yet satisfactory, generally using automated testing. There is no requirement for a meaningful attempt by the suggested due date and your automatic extensions cannot be used for the final deadline for these assignments.
Exam (and optional retest): There will be an exam (approximately ⅔ through the semester). The midterm will be on paper and will cover both the specific technologies we use in class (e.g. JavaScript) and general SW development principles, patterns and best practices. The specific questions will be tied to our class learning targets. Later in the semester here will be an optional retest with new problems for each of the learning targets (i.e., no new material). You are encouraged to solve any of the problems for which you have not already earned a Satisfactory mark.
Project: The focus of this class is the final project. In the second half the semester you will undertake a large software development project as part of team of 5-9 students. You will need to be in frequent contact with your group and actively contributing as a software developer each week. Your team will receive regular feedback throughout the project. The final rubric will be developed as part of class, but will include the overall success of project, but more significantly your participation and contributions to the project in both programming and non-programming activities. Our goal is to grow as software developers. To do so requires focusing on the practice of software development itself (as opposed to just number of features implemented or other similar metrics). You will submit regular status reports summarizing your contributions and will also be evaluated by your peers.
Final grades: Final grades will be determined by the following bundles (subject to change):
Final Grade | Bundle |
---|---|
A | Earn M+ (>= 3) on all programming assignments with >M (>3) on at least 2 assignments, and Earn S on 9/10 practical exercises, and Earn an S on 7/8 of learning targets (exam problems), and Make multiple meaningful technical contributions (or equivalent) and non-technical contributions to the final project |
B | Earn M+ (>= 3) on all programming assignments, and Earn S on 8/10 practical exercises, and Earn an S on 6/8 of learning targets (exam problems), and Make a meaningful technical contribution (meeting expectations) and non-technical contributions to the final project |
C | Earn M+ (>= 3) on 3/4 programming assignments, and Earn S on 7/10 practical exercises, and Earn an S on 5/8 of learning targets (exam problems), and Make technical and non-technical contributions to the final project |
D | Earn M+ (>= 3) on 2/4 programming assignments, and Earn S on 6/10 practical exercises, and Earn an S on 4/8 of learning targets (exam problems), and Make some but minimal technical and non-technical contributions to the final project |
The “+” and “-“ modifiers will be applied by the instructor to the base grade above when the work completed falls in between bundles, e.g., an “A-“ would be assigned for work that is close to but not does meet all the requirements for the “A” bundle and “B+” would be assigned for work that meaningfully exceeds the “B” bundle requirements but is not close to the “A” bundle.
Expectations of Students
You should expect to spend up to 10 hours per week on work outside of class to be successful in this course. If you find that you are regularly spending more time than 10 hours per week on the class, send me an email or stop by drop-in hours to chat.
Course Materials
Textbook
There is no official course textbook, although you may find the following books helpful:
- Engineering Software as a Service: The book associated with a similar course at UC Berkeley. While this books is focused on Ruby and Rails, the language-independent topics are very relevant (e.g. development process). This book is now freely available for download.
- Eloquent JavaScript: A free e-book introduction to JavaScript.
Software Setup
Please review the Getting Started page for a guide to obtaining and installing the necessary online accounts and software.
Course Policies
Resources Available to You
We have many resources that can make the learning process easier throughout the course:
- Professor Drop-In Hours: My drop-in hours are a great place to ask questions! You can ask questions about your homework, the lecture, the CS major, CS research, working in tech… even your general experience at Midd!
- ASI Drop-In Hours: Smith (our Laboratory Instructor) and Noah (our ASI) are available to help with questions about 312 during their drop-in hours. See their hours on on their personal website (Smith, Noah).
- Course Assistant Drop-In Hours: Course assistants will also be available to help students with their coursework. Their schedule will be available early in the semester.
- Ed Message Board: Ask questions about course content and assignments on the Ed message board. Asking questions here allows your classmates to see answers to frequently asked questions. Do not share code for any assignments publicly on the message board. If you need to share code, please do so but pushing to github.
- Email: If you have a question that cannot be asked on a public message board, please send an email to lbiester@middlebury.edu. I will commit to responding to emails from students within 1 business day; I will not respond to emails on the weekend.
Extension Policy
You may take up to two (2) three (3) 24-hour extensions on the initial (not final) due date on the practicals and programming assignments at your discretion (no explanation required or desired).
Only one extension per assignment is permitted. See the process for using your extensions here. Other than the two extensions described above, we will not accept late assignments except under extenuating circumstances.
Laptops
You are expected to bring a charged laptop to all class sessions. If you don’t have access to a laptop (even if for just a single class period), please contact me to ask about the availability of the department’s loaner laptops. The CS Department maintains a set of loaner laptops, preinstalled with relevant course tools, for both short-term and longer-term use. Given the small number of machines available (approximately 10), if you anticipate needing a laptop for a longer period (e.g., the entire semester or more), I encourage you to also inquire with the library about loaner equipment and/or Elaine Orozco Hammond about an Opportunity Grant, which can help you to purchase a laptop. Our department commits to meeting the needs of every student, so please don’t hesitate to contact Smith (our ASI) if you need a computer (in any way) for this course.
Honor Code
You are encouraged to discuss material from the lectures and online resources with your classmates, to post questions (and answers) to Ed, and are welcome to provide advice and help a classmate hunt for bugs. But you need to do so in a way that respects others’ work and contributes to your and your classmates’ learning (rather than hindering learning).
The work that you turn in must be completed independently, unless an assignment is explicitly designated as a “team” assignment. Helping a classmate or working together does not mean working jointly on the same solution (on the same or different computers). You should never copy another students code or solutions, or exchange computer files, until after the final due date for assignment. If you see substantial portions of someone else’s solution in the process of helping or being helped, you should not copy it. Step away from your solution for an hour and then complete the assignment independently later. Alongside manual inspection, I may use automated tools for detecting software similarity.
You are permitted (and encouraged) to search online for documentation about the tools and technologies we are using, and consult the various online and offline resources for hints, techniques, and code snippets. You may and are encouraged to use any code that we provide to you. Any code that you didn’t write, or we didn’t provide you, must be cited (e.g., by providing the URL in a comment) in accordance with its licensing terms. Large language models (e.g., ChatGPT, GitHub Copilot) are a permitted resource (we will discuss them in class and I use them when preparing course materials), but you must cite their use in a comment. You are not permitted to search for solutions to the assignments themselves, e.g. if the assignment is to implement Tic-Tac-Toe in JavaScript, searching for “tic-tac-toe javascript” is not permitted. Assignments and solutions from previous semesters or other similar courses are not allowed resources (even if available freely online); consulting such materials constitutes a violation of the Honor Code.
As described above, attribute any ideas, code, etc, that you incorporate directly or indirectly into your work (this goes for classmates, books, online resources, large language models, etc). Be explicit. Tell me (e.g. in a comment) where you got the idea, approach, technique, code snippet, etc. and explain what your contribution was.
If you are ever unsure about what constitutes acceptable collaboration, acceptable use of Google, StackOverflow, ChatGPT, etc. or permissible resources please ask!
Disability Access and Accommodation
Every class is made up of learners with different access needs. My goal is for each student in our class to succeed, and to create an accessible learning environment for everyone. Students who have Letters of Accommodation in this class are encouraged to contact me as early in the semester as possible to ensure that such accommodations are implemented in a timely fashion.
For those without Letters of Accommodation, assistance is available to eligible students through the Disability Resource Center (formerly called Student Accessibility Services). All discussions will remain confidential.
Please contact one of the ADA Coordinators at ada@middlebury.edu for more information.
Academic Integrity
As an academic community devoted to the life of the mind, Middlebury requires that every student complete intellectual honesty in the preparation and submission of all academic work. Details of our Academic Honesty, Honor Code, and Related Disciplinary Policies are available in Middlebury’s handbook.
Honor Code Pledge
The Honor Code pledge reads as follows: “I have neither given nor received unauthorized aid on this assignment.” It is the responsibility of the student to write out in full, adhere to, and sign the Honor Code pledge on all examinations, research papers, and laboratory reports. Faculty members reserve the right to require the signed Honor Code pledge on other kinds of academic work.
Tentative Schedule and Topics
Week 1: Introduction, Javascript (Tu), Javascript, cont. (Th)
Week 2: Testing, TDD, Static Analysis (Tu), Introduction to React (Th)
Week 3: React components (Tu), React testing, NextJS (Th)
Week 4: Consuming REST APIs (Tu), Behavioral testing, User stories, Lo-fi Mockups (Th)
Week 5: Version control, CI/CD, deployment and DevOps (Tu), Agile development processes
agile and scrum video
working as a team video
(Th)
Week 6: Sprint 0 planning
project proposals (Tu), Servers, Creating REST APIs, Models (M in MVC) (Th)
Week 7: Sprint 1 planning (Tu), Databases, Models, Associations, RDBMS (Th)
Week 8: RDBMS, ORM (cont.) (Tu), Deployment, Monitoring, Performance (Th)
Week 9: Sprint 1 Demo, Sprint 1 Retrospective, Sprint 2 planning (Tu), Authentication (authn) and Authorization (authz) (Th)
Week 10: Code hygiene, Refactoring, Legacy code (Tu), Design patterns, SOLID (Th)
Week 11: Sprint 2 Demo, Sprint 2 Retrospective, Sprint 3 planning (Tu), Usability Testing (Th)
Week 12: SW development case study (Tu), Responsible developer?, Wrap-up (Th)
See the detailed schedule for more!
-
Your grade in this class will also be determined in part by your ability to meet certain deadlines. The initial deadlines for meaningful contributions are designed to ensure that you are putting some work in to the class each week, and the deadline halfway through the semester is necessary to prepare you to make meaningful contributions to the final project! Deadlines are also important in the real world - for instance, as a software engineer, I worked on GDPR compliance, which had a hard deadline set by the government! ↩