This is a class about making software in teams; you'll ship 2 versions of a web application while learning about the many underlying theories and methods in software engineering.
This syllabus is organized as follows:
The centerpiece of this class is your team's software development project. Your team project will take place over 10 weeks and involve two deployments. The first deployment is based on the requirements document on the right; the second deployment is based on requirements that your team specifies in week 8. The very first thing you do for this class is read this document.
who's on my team?
Your team will consist of 4 classmates. We will assign teams based on a survey you complete in the first day of class. You will not be able to choose your teammates, but you will have an opportunity to indicate (1) what skills you excel at and (2) what skills you'd like to learn. We will attempt to ensure that all teams have at least one person with client-side web development skills.
There are a number of reasons why you can't choose your teammates. First, you rarely get to choose who you work with in the professional world. Second, this is very much a class about learning to work with people effectively, regardless of their personalities. I won't explicitly design groups to cause interpersonal friction, but some friction is inevitable between teammates who don't know each other well. This is your chance to learn how to succeed as a team despite social loafers and micromanaging managers.
who does what?
Software teams are composed in a variety of ways, with a variety of roles. There are often managers, developers, testers, designers, technical writers, support staff, marketers, and a variety of other more specific roles. Since your teams will only have 3 or 4 people, it won't be possible for you to have such explicit roles. Instead, it's worth considering the various responsibilities you'll have and who might be best qualified to take them on. These responsibilities include:
- management. Who can lead? Who can be the holder of the vision of the project? Who's willing to resolve disputes, manage scarce resources (like developer talent), and track progress toward goals?
- testing. Who has an eye for detail? Who's comfortable ensuring your team's code does what you intend? Testing is all about quality control. Who has an eye for quality?
- designing. Who will keep the user's needs in mind? Who will discover user needs? Who will call into question implementation decisions that oppose user needs? Who will do the usability testing?
- writing. Who will write written content and documentation for the team, to ensure it is understandable to the intended audience?
- support. Who will manage the public face of the project? Who will triage newly reported issues? Who will ensure that deployments go smoothly?
- marketing. Who will make sure that potential users know about the software? Who will make sure users know about the software and can find it?
All of these responsibilities will play a role in your success this quarter, and you may take on a variety of them across the quarter. In other words, I will not assign these responsibilities. Instead, you and your team will decide who does what, thinking carefully and deliberately about who should be doing what and when based on their skills, availability, and communication skills.
who are the users?
Since this is a user-centered design course, you might be wondering for whom who you're engineering this software. The answer is that your making this software for Informatics students. They are the ones whose needs you are satisfying and they are the ones who you should study and test with. If you decide to have a design role on your team, a central part of their responsibilities should be doing user research on your classmates needs and activities and testing the usability of your software with your classmates.
You're also welcome to share code with other teams in the class. However, remember that you are competing with other teams for 10 points at the end of the quarter, so it may be to your advantage to minimize how much you share with other teams. They are, after all, your direct competitors.
Your grade will be based on a 100 point scale:
All points are worth the same amount, regardless of what category they come from. Your points will be converted into a grade point with approximately the following formula:
There are likely some edge cases due to rounding differences on GradeBook.
This formula produces this mapping:
|≥ 97 points||4.0|
|≤ 59 points||0.0|
Finally, there are a few important policies that I will strictly enforce:
- No late work will be accepted for any of these, except for document health reasons or other circumstances outside your control.
- No extra credit opportunities will be provided.
My philosophy on grades is that if you show up and turn everything in, but do everything to the lowest level of quality, you should be able to get a 0.7 (D-). There are no A's for effort in this class. To really earn your A (or B or C), I expect quality. I will do my best throughout the quarter to convey what quality means, but if you're still confused, I expect you to ask me or the TA.
deliverables (50 points, 5 points each, team)
Deliverables are assigned on Fridays and due the following Friday. Details about the deliverables and their grading criteria can be found in the links in the schedule. All members on a team will receive the same score for each deliverable (even if you believe one member's contributions were minimal). You are encouraged to apply the teamwork skills discussed in class to maximize everyone's contribution to your team deliverables.
Most of your deliverables will be "submitted" by attaching them to your project wiki. We'll check their attachment times to ensure they're not late and download local copies for review. Details about where to attach your deliverables will be specified in each deliverable's description.
2.0 release quality (10 points, team)
A portion of your grade is explicitly based on the quality of your team's 2.0 deliverables. What counts as quality is not up to the software team, but the market to which the team's software is deployed. Your market is the all of your classmates.
You will individually rank all projects in class, including your own, twice: once after version 1.0s are deployed and another time after version 2.0s are deployed, during finals week. The first ranking your team receives should help your team get feedback about why you received the ranking and help you improve your ranking for the second time, when it actually counts toward your grade. To rank the applications, you'll individually try all of the deployed applications and rank order them based on which you would personally prefer to use to take notes.
To actually perform the ranking, you will be responsible for going through each other team's application, trying its major features as if you were considering adopting it for your own personal use. You should take detailed notes about your experience as you do this. Once you've gone through every project, decide an a ranking for all of the projects, from 1 to the number of teams in the class, and write a 500 word rationale for your ranking, explaining the qualities that you used to determined your ranking. You'll then submit these assessments to the ranking survey.
To convert the ranking into points, we will determine each team's median rank of all ranks chosen by your individual classmates. Your 2.0 release rank points will then be computed as follows:
If your teams median rank was 1 and there were 10 projects, then your points would be 6. If your team's median rank was 8, then your points would be 9.
Think about the implications of this scoring process. These might be the only points standing between you and a 4.0. What will you do to ensure a high ranking by the end of the quarter? You certainly can't bribe everyone in the class. (Well, you can try, but someone will probably tattle). Instead, you'll need to test a lot. Test your application with as many of your classmates as you can! The more feedback you get about your users' experience with your application, and the more you do to address it, the higher your median rank will be. Apply everything you learned in INFO 360 to get quick, targeted, effective feedback, and compete for the high rankings.
The schedule for the 2.0 ranking is as follows:
- 2.0s are deployed Tuesday of finals week at 5pm
- rankings are due Thursday, 5 pm
- ranking results will be posted Friday, 5 pm of finals week
If you do not submit your rankings by the deadline, you will not receive credit for this portion of your grade!
communication quality (10 points)
Every two weeks (a total of 5 times), your team members will anonymously evaluate your communication skills. This should provide you feedback about how well you're coordinating with your team and, if your score is low, it should prompt you to discuss with your team how your communication might improve.
Each of your teammates will respond to the following two questions:
In the past two weeks, I knew what this teammate was working on:
In the past two weeks, I knew when this teammate expected to finish her/his work:
We will keep track of your teammates' responses to these questions across the quarter (if you have two teammates, you should have 5 × 2 = 10 ratings by the end of the quarter; if you have three teammates, you should have 5 × 3 = 15 ratings). At the end of the quarter, we will determine the median response you received for each question on a 1 to 5 point scale, where "never" is worth 1 and "always" is worth 5. For example, if the median response to the first question was "usually" and the second question was "rarely", you would get 4 points for the first question and 2 points for the second question, for a total of 6 points out of 10.
The TA or I will send out the link to the survey soliciting your responses on a bi-weekly basis. Late or missing submissions will be docked 2 points (since late work is not accepted).
work diary (10 points, due before the final exam period)
The purpose of a work diary is to reflect on your work as you do it, individually, across the whole quarter. The content of a work diary is quite simple, consisting of a timestamped log of thoughts and notes during your work. These thoughts can include problems you're stuck on, issues you're having with your team, stream of consciousness thoughts about your project, reflection about the quality of your work and productivity, and content you've found throughout your process that you've found useful for your work (such as examples).
Work diaries are useful for several things:
- They are useful evidence for evaluations of your work. It enables you to go back and clearly communicate what you accomplished. This is true not only in school, but in annual evaluations in the workplace.
- They provide an opportunity to think about whether your team's process (and your role in the process) is effective. For example, you might reflect in your diary about ways you might be more productive).
- They provide a central place to brainstorm and sketch solutions to design and implementation problems verbally
- If one is disciplined enough to write in the diary at the end of a work session, they can be helpful in resuming work the next time you work (reminding you what you were working on).
What makes a good work diary can depend a lot on your role in your team and your personality. Some will focus more on implementation problems and others will focus more on management. There are no particular requirements about what you write in your diary, as long as it concerns your work in this class.
There are some things that good work diaries have in common. These are the things that your work diary grade will be based on:
- frequency (6 points). Work diaries are only useful if you write in them regularly. Your diaries should contain at least
3 entriesone entry per week, for a total of 10 entries. We will not be considering when these are written, so it is reasonable to save them for the end of the quarter, once you've had a chance to reflect on the work. Your score on this will be be calculated with the following formula: max(6, round((|entries| ÷ 3010) × 6)). This will be assessed independently of the content of your entries; they could be as short as single sentences and you would still get credit. Note that you can write more than 3010 entries, but you won't get more than 6 points for frequency.
- reflection (4 points). Work diaries are only useful if you use them to reflect on your work, your team's process, and the problems you're solving for your project. Therefore, we will read your entries and classify each entry as either reflective or not. Reflective entries evaluate your work: are you happy with what you've accomplished? What are you stuck on? Could you have communicated better with a team member? What's holding back your team's productivity? Here are a few entries from my own work diary on a recent project:
- "I just spent 3 hours debugging a problem that I could have avoided by doing more thorough testing. It was just a simple typo that I overlooked. The next time I make a change with copy and paste, I'm going remember to do lots of testing of the code to execute each of the changes I made. It never helps to be in a rush."
- "It seems like every morning I have an amazing burst of productivity at, until around noon, when things really start to drag. I'm going to start putting all of my serious thought work in the morning and save the mindless but inescapable busy work for the afternoon."
round((|reflective entries| ÷ |entries|) × 4.5)This is roughly based on the proportion of entries we mark as reflective.
how to format and submit
Your work diaries should be private, so you feel free to talk about your teammates or other difficulties you'd rather not share with your teammates (although for most difficulties, you should probably mention them so you can get help, rather than struggle alone). You can keep your diary wherever and in whatever document format you like, but the text itself should be formatted as follows:
October 14th, 2010 I Worked in the lab today and accomplished nothing. Partly it was because I was so tired; I didn't sleep at all last night and it's really hurting my productivity. I'm starting to think that it's actually caffeine. I have a latte every afternoon at 4 and just feel wired until 2 am...
(Note that this post is borderline reflective: it doesn't really explain the connection between sleep and accomplishing nothing, but it's getting there). At the end of the quarter, you'll submit your diary on Catalyst, where only I will have access to it.
activities (10 points)
In each lecture, we will often apply the concepts in the lectures by engaging in an in-class activity. We will gather your signatures at the end of class to give you credit for participating in these activities. At the end of the quarter, you activity score will be computed as follows
This is the proportion of all activities that were run, allowing you to miss up to 3 activities.
readings (10 points, 1 point each, due Wednesdays)
All readings are done individually and will involve reading a section of the required book or another article and writing a response to a prompt. Each reading is worth 1 point, and will be assessed as follows:
- 1 point. The response is explicitly tied to the prompt through explanation, perhaps through example, argument, or citation of the original text.
- 0 points. The response is either weakly connected to the prompt, answers the prompt incorrectly, or the response was not posted by the deadline.
These criteria were designed to encourage you not just to read the assigned text, but to get you to think about the relationship between it, your experiences, and other phenomena in the world.
Your reading responses should be posted on the class reading forum. Only reading responses posted by the beginning of class on the due date will be accepted for credit.
Creating software requires a lot of tools. Below are the details about what you'll need.
revision control, issue tracking, wiki
Nearly all of your work this quarter will be submitted to BitBucket, a software project hosting site for storing your code, tracking issues, managing versions, and documenting your progress.
Another essential tool is a nice HTML/CSS/HTML editor for the implementation work you'll be doing. Whatever editor you choose, I expect you to learn how to use it yourself and lean your classmates if you run into trouble. The TA and I cannot be experts on every editor out there; we'll provide support for the tools we require you to use (namely Trac and Subversion).
Here are a number of editors that have been recommended to me for basic web development:
- Coda (Mac only, $79). A great editor, integrating a GUI front-end for Subversion repositories, FTP client, web development documentation, and debugger. It is Mac only, but if you're a Mac user or primarily use the computer lab machines, it's one of the best editors out there for web development.
- TextMate (Mac only, $49 - 15% for education discount). A standalone editor with a healthy collection of plug-ins.
- Zeus (Windows, 45 day trial, $70). Comparable to Coda, but not as slick, integrates FTP and SVN commands in a single UI.
- Eclipse (cross-platform, free). A complex, bloated, but powerful IDE with a steep learning curve. You'll need the Aptana plug-in for web development and either the Subclipse or Subversive plug-ins for Subversion integration
- IntelliJ IDEA (cross-platform, 30-day trial, $99 or free if the uses it)
- Notepad++ (Windows, free). A nice editor with an SVN plug-in.
If you have others you'd like to recommend to your classmates, let me know and I'll broadcast them.
UW web hosting
You'll deploy your projects to one of your teammate's UW student space. LST provides some reasonably clear instructions about how to do this. If you haven't done this before, be sure you try it in advance. (There's nothing worse than rushing the configuration of web technologies, because there's always something you'll overlook when in a hurry!)
The following paragraphs discuss academic integrity, copyright and privacy concerns governing student conduct in the iSchool and the University of Washington. They apply to all assignments and communications in this course.
The essence of academic life revolves around respect not only for the ideas of others, but also their rights to those ideas and their promulgation. It is therefore essential that all of us engaged in the life of the mind take the utmost care that the ideas and expressions of ideas of other people always be appropriately handled, and, where necessary, cited. For writing assignments, when ideas or materials of others are used, they must be cited. The format is not that important as long as it is consistent, the source material can be located and the citation can be verified. In any situation, if you have a question, please feel free to ask the instructor or teaching assistant. Such attention to ideas and acknowledgment of their sources is central not only to academic life, but life in general.
Please acquaint yourself with the University of Washington's resources on academic honesty
All of the expressions of ideas in this class that are fixed in any tangible medium such as digital and physical documents are protected by copyright law as embodied in title 17 of the United States Code. These expressions include the work product of both: (1) your student colleagues (e.g., any assignments published here in the course environment or statements committed to text in a discussion forum); and, (2) your instructors (e.g., the syllabus, assignments, reading lists, and lectures). Within the constraints of "fair use," you may download or copy slides, recordings or notes for your personal intellectual use in support of your education here in the iSchool. All of these examples are copyrighted expressions, and fair use by you does not include further distribution by any means of copying, performance or presentation beyond the circle of your student colleagues in this class. If you have any questions regarding whether a use to which you wish to put one of these expressions violates the creator's copyright interests, please feel free to ask the instructor for guidance.
To support an academic environment of rigorous discussion and open expression of personal thoughts and feelings, we, as members of the academic community, must be committed to the inviolate right of privacy of our student and instructor colleagues. As a result, we must forego sharing personally identifiable information about any member of our community including information about the ideas they express, their families, life styles and their political and social affiliations. If you have any questions regarding whether a disclosure you wish to make regarding anyone in this course or in the iSchool community violates that person's privacy interests, please feel free to ask the instructor for guidance.
Knowing violations of these principles of academic conduct, privacy, or copyright may result in University disciplinary action under the Student Code of Conduct.
students with disabilities
To request academic accommodations due to a disability, please contact Disabled Student Services: 448 Schmitz, 206-543-8924 (V/TTY). If you have a letter from DSS indicating that you have a disability which requires academic accommodations, please present the letter to the instructor so you can discuss the accommodations you might need in the class.
Academic accommodations due to disability will not be made unless the student has a letter from DSS specifying the type and nature of accommodations needed.
student code of conduct
Good student conduct is important for maintaining a healthy course environment. Please familiarize yourself with the University of Washington's Student Code of Conduct.