MIT 6.S194 | Open Source Software Project Lab  

Design Studio

Goal

A way for you practice communicating, critiquing, and iterating technical design.

High Level Process

Each Wednesday, four individuals will present a technical design and implementation that they have worked on. This means you can expect to present roughly once every three weeks.

Assignments for which groups will send up presenters will be on the course calendar.

Presenter Role

When you are acting as presenter, your role is to communicate your work in a way that both conveys its technical design and also the reason why this work was necessary. A presentation should last about ten minutes. A good breakdown for these ten minutes would be:

  • Introduction: One or two sentences about what you're going to be presenting.
  • 2 Minutes: Broader context of the problem.
    • What is the software involved and who uses it?
    • What is the particular area of the software that you've been working in? (i.e., the database layer, the reporting code, the front-end interface). Who uses this layer software? What is its significance to the project? What is its design philosophy? Its goals?

    For example, if you are working on a bug-fix for a database library, explain the database library to us -- who uses it? Why? What is its overall design philosophy? How does it integrate with other components?

  • 3 Minutes: Technical overview of the feature, bug, or design task that you have been working on. Why is it important or necessary? How will it affect users? What technical details are involved? What are some of the risks and tradeoffs involved? What is interesting or hard about this problem? If relevant, have code prepared to show.
  • 2-3 Minutes: Your solution, even if its still in progress. Why did you make the choices you did. Have code prepared to show

Audience Role

The audience has the responsibility to ask questions which probe the design space and the presenters decisions. Avoid problem solving: this is a space to understand and critique a particular idea rather than solve problems.

The second role of the audience is to provide feedback. Focus on how or why the proposed design is good or unfitting for the problem. This includes both technical (i.e., code technique) and design feedback.

Keep in Mind

  • Be expedient and to the point.
  • Appreciate and respect the importance of "ordinary" technical decisions. Especially at MIT, we all have a tendency to disregard technically easy things as being uninteresting. Do not. We aren't interested in the technical difficulty of solutions here. We are interested how and why you decided your solution is the right solution. And the challenge of picking the right solution is nearly always interesting to talk about, even if all the choices you are choosing between are technically simple to implement.