
![]()
![]()
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.

I love how it works. To use it, you sign up using a one-page form, and you’re then set up with your own account (accounts are free during their beta, but it’s not clear how long they’ll be in beta). You then set up your own alert software to send emails to PagerDuty whenever you want a notification (this is the most time-consuming part because you’ll need to set up each monitoring software individually). PagerDuty doesn’t do the actual monitoring; rather, it receives alert messages via email and routes them to the right person on your team based on rules you build. Alerts can be in the form of SMS, phone calls, or email.
One of my favourite parts of the software is the great UI on the built-in calendar that allows you to set up which person on your team is on-call at any time.





If you are like me, your blog aggregator is getting a little out of hand. Once you start climbing over 150 feeds, and well in to the 200s, you are starting to get overloaded. I have, on a few occasions, deleted all the feeds from my feedreader and have started from scratch.

