Software Studio

The Idea

The essence of the software studio is the concept of reflective practice. The computer science professional solves problems for a living. To each new problem, the professional needs to understand and draw from the vast technical knowledge that is common to all solutions. At the same time, each problem presents new difficulties that demand new solution. This interplay between the analytic and the artistic is the hallmark of the professions. Many people are reluctant to acknowledge the artistry required in their profession, but it is the conclusive factor in a professional's expertise.

The task for computer science educators, then, is to help students learn how innovate and invent. Innovation occurs in adapting old solutions to new problems. Invention is required where past solutions are insufficient. More traditional courses can teach the technical, analytic skills needed by a professional, but most often these skills require application to real problems in order to become part of the student's expertise. More traditional courses are almost entirely inappropriate for helping students to develop the creative, artistic side of their skill set.

The term "studio" is derived from the teaching process used in schools of architecture and art. It indicates a different course organization and reinforces the intent that a course pays special attention to the artistic skills of the profession.  For example, consider the following description of studio classes taught in a school of architecture (extracted from  Teaching HCI Design With the Studio Approach, by Yolanda Reimer and Sarah Douglas (2003)).

Scheduling and Format

Each term, in addition to regular lecture courses, architecture students are required to enroll in a studio class tailored to their skill level in the program. Studio classes are held 3 days a week, 4 hr per day. Each studio class takes a real-world architectural problem and requires students to produce a final building design through an iterative design process. Problems vary by complexity of function, complexity of environmental conditions, or other aspects depending on the skill level of the students. Each week the instructor will emphasize the design of a particular architectural aspect, such as form, site location, function, and so forth, of the overall project. Depending on the studio class, students often work in collaborative teams to produce a joint design.

Studio classes are held in specially designed rooms and the size of the class is limited to 10–12 students. Students are assigned large drafting-style desks where they work on their design projects both during class and outside classroom time. This is the student’s private workspace for the duration of the term. In addition to the desks, an open area with table, chairs and pin-up wall space is maintained for group conferences.

All of the studio classes are highly interactive (faculty to student; student to student) and involve regular design critique – or crit – sessions. The format of a typical 3-hr studio session is as follows: students work at their desks informally (i.e., they are free to talk with one another, play music quietly, etc.) on their current design project until it is time for them to meet with their instructor for a crit session.

Design Crits

The design crit is the central means of conveying design knowledge. Instructors usually gather from 2 to 4 students together at one time. Each student either brings his or her drawings over to the common meeting area or pins them up on the wall for review. Design representations are often low- fidelity sketches to promote the general communication of ideas and to enable students to throw away bad designs. While the instructor focuses on the work of one individual at a time – taking between 20 and 30 min – the remaining students benefit from the comments made by the faculty member and student.

Design crits start with the student explaining how he or she is meeting the particular design emphasis for the week. To keep the critiques positive, reviewers generally begin their comments with statements like ‘‘I like what you’ve done with –’’. Many reviewers then use the Socratic method to ask the student a number of strategic questions which serve to highlight perceived weaknesses with the design. Reviewers often end their critique by suggesting similar problems/solutions done by well-known architects, and by asking the student if he or she has any specific problems and/or questions they wish to ask. Finally, faculty reviewers will also make helpful suggestions on the student’s presentation itself (e.g., urging the student to frame the problem and to discuss his or her goals overall before getting into details). This provides the student with direction for future success, both in the current class and elsewhere.

In addition to the format of the design crit session described above, there are midterm and final ‘‘pin-up’’ sessions. Midterm pin-up sessions are slightly more formal than the day-to-day crit sessions in that they typically signify important milestones in the project design process, and they are analogous to midterm exams. During a pin-up session, each student’s work is reviewed separately by two Architecture school faculty members and by a peer. Each review session lasts approximately one-half hour. While a student is having his or her work reviewed, other students in the class are free to sit in and listen and learn. The final session of the term is a formal design crit by invited professional architects. Studio classes are graded on a Pass/Fail scale, so as to encourage collaboration among students.

To summarize, the studio model we observed has the following characteristics:

As the reader can see, studio teaching is radically different from the usual computer science instruction of lecture/lab/discussion. Studios can be characterized as a form of social constructivism applied to education (Lebow, 1993). The philosophy of social constructivism emphasizes context and the integration of thought and action. It turns the usual instructional model around claiming that ‘‘what the student does is actually more important in determining what is learned than what the teacher does’’ (Shuell, 1986). Rather than students being passive receptacles of transmitted knowledge, students must do the most work! This approach to education is particularly effective when learning is open-ended, focusing on complex contextual problem solving that demands a high degree of analysis, idea generation, reflection and communication. This is exactly the situation that we encounter when teaching design (Petroski, 1996).

Interest in studio approaches has grown among folks in the computing industry over the last few years. Check out RoleModel Software, which is a company that uses the studio model and apprenticeship learning (and extreme programming) as its way of doing business.

Tomayko says "The method of the studio is constant questioning." The student is forced to explain and defend the choice of proposed methods, processes, solutions, and implementations. She must relate these choices to other parts of the problem and solution and convince others of their adequacy.

This constant process of reflection, brought about personal questioning as well as external criticism, leads the student to develop a much deeper level of understanding of her technical domain knowledge than might otherwise be achieved. She also comes to experience this knowledge in the context of real problems and real solutions, and to learn and hone artistic skills at the same time.

The course "instructor" metamorphoses into something of a coach: a sounding board for ideas, a constant critic who helps the student see other alternatives, and a source of direct instruction when new technical knowledge is needed. The faculty member's involvement in the studio is intense and time-consuming. This kind of involvement is, in fact, a source of learning for the instructor.

The Implementation

This isn't a perfect studio approach. 

For starters, we will not focus exclusively on the studio approach.  Many days (in particular early in the semester), will be largely spent in a "round-table" atmosphere where we discuss AI topics that will hopefully have an impact on how you built your final systems.  While you gained a generalized background in Artificial Intelligence in the AI course last semester, you will find that it is worth revisiting some of these topics in light of a specific project.  Furthermore, we will discuss some issues that were too advanced for an intro AI course or go into more detail than was possible in this course.  All of this will give you a better depth of tools to use in solving your particular problem.  In a true studio-based program you would still be taking these content courses, but you would be taking them separately from the actual studio.

Second, the standard university 50 minute or 75 minute "lecture period" isn't quite enough time to really get into the true swing of the studio approach.  A studio approach would probably have enough time for you to work for a while in your groups, gather in a central location to discuss your project with your peers and me, and then have you return to your groups to work some more while I moved around and provided further guidance as needed.  Furthermore, even if we had the time, we don't have perfect resources.  Since the "design" in this course is based around software it would be better if we were in a room with *gasp* computers!  While we will haul in computers many days, the overhead is time consuming and we share this room with many individuals.  Thus, we just "make do."

In order to adapt for these situations, we will largely "simulate" the studio with two different types of activities on different days - design critiques (DC) and "guided practice" time (GP). 

Approximately one day every two weeks will be devoted to "crits."  We will conduct design and code walkthroughs, oral reports of more and less formal varieties, technical reviews, and team discussion. At various times, the teams will discuss their project with the other teams, both as a means of consolidating ideas through expression to a technically-adept but unrelated audience and as a means of getting useful feedback from other professionals. This is more than the simple "status update" that you may have provided in other courses.  Those were normally short (ten minute?) sessions where you said "Here is what we have at this point."  In this course you will be responsible for leading a discussion for approximately 20-25 minutes.  While part of this discussion will be "here is WHAT we have" the focus of your presentation should be based around WHY you have what you have.  What options have you considered?  How would each of these options have affected your final project?  Why did you choose what you chose?  You should also attempt to engage the other members of the course in a discussion about how they might have solved it if they had to make the decision and how the decisions you made might be used as part of the solution to their problem.

Guided practice days will often involve bringing in a couple of laptops for each team.  During those sessions you can spend some time working with your teams in a setting where I can provide less formal critiques.  While it is easy to think about these days as simply "free work" days you should treat them in the manner they are intended.  These are days where your team can meet, work on the design of your code, ask questions of the instructor and your fellow classmates, and legitimately LEARN about how to build intelligent software.  That isn't to say that some of these days won't be spent in "geek on a coding run" mode, but you should take advantage of having non-team members in the room with you (both myself and your fellow classmates) to discuss issues with or help you find alternatives and solutions.

While no single day's activities are a true studio, the three different activities when viewed as a complete unit should provide a pretty reasonable approximation to the studio approach and provide you with a much better learning experience than the traditional projects course.