Some rights reserved by SteveGarfield

About 5 years ago I was asked to teach a 4th year undergrad software engineering course at the University of Toronto. The course had been previously cancelled due to low enrollment; in an era dubbed the “Software Gold Rush” a cancelled course indicated something was wrong…

Software engineering is difficult to teach
Students are expected to learn how to avoid mistakes they never made. A great divide results from the instructor talking about concepts suitable for a mature organization when students are all about working their ass off and getting things done the night before. We borrowed several lessons from startups, having been personally involved with two startups over a dozen years. The way startups work are much closer to students ways of doing things. Since launch, course enrolment has tripled and two Y Combinator applications have been submitted based on class projects. Here is what we have learned so far:

1. Use a startup software process
Students are all about getting things done the night before; similar to how startups work. Teaching a heavyweight process feels foreign because students haven’t made the mistakes to understand reasons for the overhead!

2. Change the project every year
There is nothing more of a turnoff than a make-work project with antiquated technology. Instructors that use the same project over and over are sleepwalking. A new project each year puts the instructor and students on equal footing, solving problems together. Make the class goal to have someone apply to Y Combinator. Discuss the non-technical issues of software such has how people are going to use the product, how are you going to sell it, what is the competition like, what is the business plan. One big class project brings issues into the classroom better resembling the real world. This also allows non-trivial projects to be developed and students to test-out roles (e.g. project management) that would not otherwise exist.

3. Allow controlled crashes
Let the students make mistakes. For example, let them avoid source control. A student who looses code because of clobbered checkins will be a lesson learned for the entire class. However, when crashes occur, it is the instructor’s responsibility to manage and fix it. After the mistakes have been made, teach them about process. Keep things light and give them references for their future travels. During lectures on process, tie them into the mistakes that were made. Make process real.

4. Demo early and often
Create a culture where the principal deliverable is working software rather than documentation. Use early demos to correct mistakes and give guidance rather than having them worry about their grades.

5. Instructors should code
The instructor-student relationship changes dramatically if the instructor contributes code. Everyone becomes a peer instantly. This improve communication and follows the startup philosophy that even managers should write code.

Next steps
The course has been well received by the students at UofT. I have much more regular contract with students from this class than the other courses I have taught at UofT and UofW. I am interested in hearing from anyone who is interested in providing continuity to the students; a partner that would provide input on the project at the beginning, stay involved with it during the course, and offer a path forward for interested students ready to commit to a startup.