Course DescriptionStartup engineering is critical to innovation. The skills required to effectively prototype, launch, and scale products are vital to engineers everywhere, from fledgling companies founded in dorm rooms to local mid-size companies to internal startups from multi-national tech giants. However, developing software in a startup environment poses unique engineering challenges. These challenges include making and justifying foundational architectural and technical decisions despite extreme uncertainty; rapidly prototyping and evaluating new ideas and features, while building minimum viable products; prioritizing engineering effort in severely constrained environments; and communicating effectively both within a small engineering team and with internal and external non-technical stakeholders. This course teaches the skills necessary to engineer successfully in a startup environment, through lectures, group projects, case study discussions, and guest speakers drawn from experienced, practicing startup engineers.
Logistics and Communication
Lectures: Tue/Thu 10:30-11:50 a.m. in WEH 5302
Tue @ 12:30 - 13:20 (Session A) in WEH 4623
Thu @ 16:30 - 17:20 (Session B) in WEH 5101
Waitlist: We believe the waitlist is cleared; if you disagree or are having trouble enrolling, please contact us.
Prerequisites: 15-214 or 15-213, or equivalent. The focus of this class is largely technical; the goal of the prerequisites is to ensure students should sufficient programming experience to succeed in the course.
Textbook/Readings: The subject matter of this class is at the cutting edge of engineering; as such, there do not exist (to our knowledge, at least) suitable textbooks covering the material. We will instead pull various readings throughout the semester from online sources.
Communication: The course uses Canvas for homework submission, grading, announcements, and supplementary documents. Discussion and questions will be managed on Slack. Slides, assignments, and schedule will be posted on this website. We use GitHub to coordinate group work. We will provide private GitHub repositories for individuals and groups.
Please use Slack for discussion and questions, including clarifying homework assignments.
The instructors and TAs hold weekly office hours. If you cannot make it to office hours, contact us via email (using the course-wide email address, unless the issue is sensitive) and we will find an alternative time to meet.
If you have a question or concern that is not suitable for Slack, contact the instructors via: email@example.com. Unless the subject matter is sensitive, all questions will be conveyed to all instructors before being answered, so there's no point in emailing just one of us.
Note that the list should be set to accept messages from any CMU email address; if your message is held as a non-member posting to a members list, don’t worry: we respond to moderation requests very quickly.
For sensitive matters, of course, feel free to contact us individually.
In this course, we will teach you the engineering skills necessary to succeed in the highly-uncertain environment associated with a technology startup. Our focus in this class is technical; that is, we will not be spending very much time on the business side of the startup equation (though given how much business drives engineering goals, of course we will not completely ignore it!). If you are instead interested in the entrepreneurship side of the equation, we encourage you to consider 15-390, Entrepreneurship for Computer Scientists.
This class will consist of:
- Lectures. Lectures will cover technical content, and be delivered by the professors or other instructors.
- Guest lectures and panels. We will hear from from practicing software engineers, technical and non-technical startup cofounders, and other individuals with practical expertise.
- Recitation. TAs will lead recitation, which consists of activities designed to help you apply your knowledge practically and prepare for the homework.
- Homework assignments. For the first half of the course, you will practice the skills we learn in class by working on in assigned teams on a made-up startup, "Dronuts." Most of this work will be structured as a series of agile-style sprints, to simulate as much as possible the real startup experience.
- A project. For the second half of the course, you will use your new skills to design and implement an original startup idea. Don’t worry if you don't have one; we'll help you to develop a new idea, or connect founders who have startup ideas to co-founders who are excited to help with them.
There will be one midterm exam. There will be no final exam; instead, you will present your final project.
GradingEvaluation will be based on the following approximate distribution: 50% assignments, 20% midterm, 20% final project, 10% participation.
Note: Attendance is required for guest lectures. Absences during guest lectures will result in a deduction in your overall course grade for participation.
Teamwork:Teamwork is an essential part of this course. Teams of 3-5 students will be assigned by the instructors and stay together for multiple assignments. Most assignments have a component that is graded for the entire group and a component that is graded individually. By default, group assignments will receive a single grade, for all individuals. However, we reserve the right to institute peer grading in problematic situations, detailed in the Team Policy.
Please fill out the Teamwork Survey so we can begin forming groups.
Late work: Late work will receive feedback but no credit. Due to the course's heavy reliance on teamwork, there are no late days. We make exceptions in extraordinary circumstances, typically involving either a family or medical emergency (ideally, your academic advisor or the Dean of Student Affairs should request such exceptions on your behalf). We can make accommodations for travel (e.g., for interviews) so long as you request it in advance. Always communicate with your team about such issues.
Devices in lecture and recitation: Research shows that using devices on non-class related activities harms both the device user's learning, and other students' learning as well. Therefore, in general, we do not allow the use of devices during lecture. However,, if you genuinely use your laptop for class-related activities (note-taking, etc), tell us, and we will make an exception. However, we ask that if you do so, you are careful to keep your devices in note-taking mode (and don’t stray to Facebook, homework, etc).
Note that recitation activities will often involve devices, so please do bring your laptop!
Time management: This is a 12-unit course. It is our intention to manage it so that you spend close to 12 hours a week on the course, on average. In general, 4 hours/week will be spent in class and recitation, and 8 hours on assignments. A key challenge in startup engineering is that there is never enough time to implement everything that you want to implement; it is therefore important that you practice time management, estimation, and task prioritization. We would rather you make well-justified decisions to not do something than spend tens of hours on your homework.
Note that most homework is done in groups, so please account for the overhead and decreased time flexibility that entails.
Feel free to give the course staff feedback on how much time the course is taking for you. This is especially relevant as we teach this course for the first time!
Writing: Describing tradeoffs, justifying decisions, and communicating effectively with less technical stakeholders are key learning goals of this course. Most homework assignments have a component that require discussing issues in written form or reflecting about experiences. The Global Communications Center (GCC) offers one-on-one writing help for students, along with workshops. The instructors are also happy to provide additional guidance if requested.
Academic honesty and collaboration: The University Policy on Academic Integrity applies. Most assignments are done in groups. Our expectations regarding academic honesty and collaboration for group work are the same as for individual work, elevated to the level of "group." Group members will collaborate with one another, but groups should work independently from one another, not exchanging code with other groups. Within groups, we expect that you are honest about your contribution to the group's work. This implies not taking credit for others' work and not covering for team members that have not contributed to the team.
The course also includes individual assignments and individual components of group assignments. Although your solutions for individual parts may be based on the content produced for the group component (e.g., written reflections), we expect you to complete individual components independently of your groupmates.
Regarding the internet, StackOverflow, and similar sources: In real-world development, engineers often adapt code from Q&A sites, open source repositories, or similar sources to new ends. This is acceptable in this course, with two caveats:
- You may not copy a solution for our homework assignments specifically from another student or group, even if, for some reason, that code is available openly on GitHub or elsewhere (see below on the importance of keeping your homework code).
- You must test all of your code, and those tests must pass. That is, you must understand any code you adapt from the internet, and you must demonstrate that understanding using unit tests.
Regarding solutions from other students in the course, we reuse the Collaboration Policy from 15-214, with minor modifications:
"You may not copy any part of a solution to a problem that was written by another student, or was developed together with another student. You may not look at another student's solution, even if you have completed your own, nor may you knowingly give your solution to another student or leave your solution where another student can see it. Here are some examples of behavior that are inappropriate:
- Copying or retyping, or referring to, files or parts of files (such as source code, written text, or unit tests) from another person (whether in final or draft form, regardless of the permissions set on the associated files) while producing your own. This is true even if your version includes minor modifications such as style or variable name changes or minor logic modifications.
- Getting help that you do not fully understand, and from someone whom you do not acknowledge on your solution.
- Writing, using, or submitting a program that attempts to alter or erase grading information or otherwise compromise security of course resources.
- Lying to course staff.
- Giving copies of work to others, or allowing someone else to copy or refer to your code or written assignment to produce their own, either in draft or final form. This includes making your work publicly available in a way that other students (current or future) can access your solutions, even if others' access is accidental or incidental to your goals. Beware the privacy settings on your open source accounts!
- Coaching others step-by-step without them understanding your help.
If any of your work contains any statement that was not written by you, you must put it in quotes and cite the source. If you are paraphrasing an idea you read elsewhere, you must acknowledge the source. Using existing material without proper citation is plagiarism, a form of cheating. If there is any question about whether the material is permitted, you must get permission in advance. We will be using automated systems to detect software plagiarism.
It is not considered cheating to clarify vague points in the assignments, lectures, lecture notes; to give help or receive help in using the computer systems, compilers, debuggers, profilers, or other facilities; or to discuss ideas at a high level, without referring to or producing code.
Any violation of this policy is cheating. The minimum penalty for cheating (including plagiarism) will be a zero grade for the whole assignment. Cheating incidents will also be reported through University channels, with possible additional disciplinary action (see the above-linked University Policy on Academic Integrity).
If you have any question about how this policy applies in a particular situation, ask the instructors or TAs for clarification."
Note that the instructors respect honesty in these (and indeed most!) situations.>
A note on self care
Please take care of yourself. Do your best to maintain a healthy lifestyle this semester by eating well, exercising, avoiding drugs and alcohol, getting enough sleep and taking some time to relax. This will help you achieve your goals and cope with stress. All of us benefit from support during times of struggle. You are not alone. Besides the instructors, who are here to help you succeed, there are many helpful resources available on campus and an important part of the college experience is learning how to ask for help. Asking for support sooner rather than later is often helpful.
If you or anyone you know experiences any academic stress, difficult life events, or feelings like anxiety or depression, we strongly encourage you to seek support. Counseling and Psychological Services (CaPS) is here to help: call 412-268-2922 and visit their website at https://www.cmu.edu/counseling/. Consider reaching out to a friend, faculty or family member you trust for help getting connected to the support that can help.
Working effectively in a group is a critical skill in modern software engineering, both in the startup context and generally. Group work can be hard, and not all teams succeed, and in fact a major contributing factor to startup failure is team breakdown. The educational context adds its own complexities: team members sometimes cannot prepare for or attend group sessions because of other responsibilities, and conflicts can result from personalities, differing skill levels, work ethics, working styles.
We encourage the following practices to ensure successful group work:
- Agree on a protocol for meeting and communication. Some, but not all, of these decisions will be technical (Slack? Trello?) that arise naturally over startup development.
- In the startup context, engineers must be flexible and capable of filling many technical roles. In an educational context, however, group work is most successful when groups designate clear roles, such as coordinator, scribe, monitor, and checker for each assignment. Agree on roles at the beginning of each assignment. Rotate these roles for each assignment to ensure fairness.
- Agree on meeting times and what each member should have done before the meeting (readings, development, writing, taking the first cut at some or all of the assigned work, etc.). The scribe documents the agreed tasks and deadlines and communicates them to everybody. Not objecting to the communicated protocol constitutes acceptance. Make agreements visible to every team member, with transparent history of the log.
- The coordinator checks with other team members before the meeting to remind them of when and where they will meet and what they are supposed to do. Team members notify the coordinator in advance if they cannot attend a meeting or are in danger of not making a deadline.
- All individuals perform the required individual preparation before the meeting
- During meetings/work times, the coordinator sets the agenda, and keeps everyone on task; the monitor ensures everyone understands both the solution and the strategy used to get it, and watches the time to ensure meetings stays within the agreed timeslot; and the checker double-checks the result before it is handed in, and submits it (or clearly delegates its submission, if the checker is unable to do so on time).
- At the end of each meeting, agree on the next meeting time and responsibilities.
- Review returned assignments together. Make sure everyone understands why points were lost and how to correct errors.
Preventing and dealing with problems. We encourage you to communicate openly with your teammates, which is often enough to help resolve many types of team challenges. Clearly documenting agreed-upon tasks and deadlines (see scribe role above) and tracking invested time helps in identifying issues. Renegotiate agreements when estimated time does not align with actually required time and imbalances arise. Document where agreements were not honored (what and when, and possibly why). Identify a fallback strategy, ideally in agreement with the team member who failed the agreement. In severe cases, identify how other team members can take over those tasks.
If a team member does not contribute to an assignment solution, their name should not be included on the completed work.
If the problem persists and cannot be solved within the team, the team should meet with the instructors so that the problem can be resolved, if possible. If problems continue, the cooperating team members may notify the uncooperative member in writing that he/she is in danger of being fired, sending a copy of the memo to the instructor. If there is no subsequent improvement, they should notify the individual in writing (copy to the instructor) that he/she is no longer with the team. The fired student should meet with the instructors to discuss options, such as finding another team willing to add them as a member, completing the work alone, or getting zeroes for the remaining assignments.
Consult with your instructors if a conflict arises that can't be worked through by the team.
Content ScheduleNote that the schedule of topics is subject to change; due dates for homework are fixed.
Michael HiltonE-Mail: firstname.lastname@example.orgOffice Hours: 10:00am-11:00am Mondays, Wean 5122
Heather MillerE-Mail: email@example.comOffice Hours: 4:00p-5:00p Thursdays, Wean 4128