App Lab logo

COMP 523: Software Engineering

Assignment 8: Walking Skeleton


Monday, October 18th at 8am


In most cases, projects involving more than one developer tend to accidentally minimize communication and coordination. The easiest approach—at least at the outset—is to partition up the tasks, work in isolation, and only start to integrate the pieces when everything else is done.

This approach typically ends in disaster, especially when deadlines loom (like the end of a semester). It’s only then that misunderstandings surface. In some cases, a large body of code was piled atop both sides of a misunderstanding, and both sides are (understandably) reluctant to undo so much work. Frustrations and hurt feelings abound, and the deadline slips. In the case of a project like the ones in this course, in which there is no possibility of extending the deadline, the product never comes together—sometimes despite heroic last-minute efforts by the team.

The best way I’ve found to avoid these problems is to integrate the pieces first rather than last. Misunderstandings can immediately be noticed and addressed, before any investment of time or emotion can occur. Once integration is finished, features that require further coordination between the pieces on either side of the integration start from a place of everything demonstrably working, which makes it much more difficult to deceive oneself about everything being correct.

This is the goal of the walking skeleton: get the major pieces integrated, even before the pieces are implemented. Integrate first.

In the term “walking skeleton”, both words are significant:

Note that, at this stage, bugs and crashes are tolerated. We don’t expect that just anybody can come along and use your walking skeleton without experiencing bugs. It might take you, as a sort of marionette, to use your knowledge of limitations to avoid encountering bugs.

An important type of integration is integration with infrastructure; that is, deployment. Heroku makes this easy for most projects, and the App Lab can help as well.


Create a walking skeleton, as defined above. Deploy it in a way that makes sense for your project:

Note that you may omit the authentication piece from the walking skeleton.

Post a link to your deployed walking skeleton on your project web site.


This assignment can be pretty painful! I believe the pain is worth it, for the reasons outlined above—and if you skip this step on a future project, you might learn that the pain you feel later in the project is greater than the pain of the walking skeleton.

I strongly recommend starting as early as possible and taking advantage of other resources available to you, such as the App Lab.

This assignment will likely involve reading a fair bit of documentation of tools that other people have written, and that you’re not familiar with. If you’re (understandably) in skimming mode, trying to sift through lots of text to find what’s relevant to a problem that you have, but not having much luck, consider slowing down and blocking off an hour or three to read more carefully and try to more deeply understand the underlying concepts and boundaries.