Class Notes: Week 8

Eau d'coli device-level system diagram. (Courtesy of the 2006 MIT iGEM Team. Used with permission.)

Aye yay yay! Won't we ever get away from this Eau d'E coli project? Not yet! Take a close look at the device-level system diagram. You can't see all the underlying BioBrick parts (there are ~24 parts in total). If you were the designer of this system, do you think that the system would work if you just synthesized all the DNA as a single contiguous strand, transformed this new DNA into a cell, and let your genetic program rip!? Or, stated differently, what would be your next step if you tried to get everything working at once, and nothing happened, or, even worse, your engineered DNA killed the cell?

Having a plan for testing and debugging your projects is critical. To help you think about how to develop the best testing and debug plan for your 20.020 projects, spend the next 10 minutes working with your team to outline a testing and debug plan for the Eau d'coli system. Before you get started, designate one person on your team to act as spokesperson. Once the 10 minutes are up, we'll ask each spokesperson for an accurate description of your testing and debug plan. If you're having trouble knowing where to start, you might consider:

1. Use the device level system diagram to sketch out a timing diagram (use a white board).
2. Think about what this iGEM team could have done if they just added all this DNA to the cell, and then nothing happened (no smell, or worse, all the cells died). How would they go about figuring out what aspects of the project might be working, and what other components need to be revised or fixed?
3. Finally, look again at the device-level system diagram. Is there anything about the system's design that makes testing and debugging easier or harder than it might be otherwise? Would you like to change any aspects of the system design to make testing and debug easier?

Part 2: Data-driven Decision-making

Consider once more the Melbourne 2007 iGEM project introduced during Week 1. In a series of questions at the end of their presentation video, the team gets asked about any changes to the gas vesicles device that might allow gas-filled cells to become even more buoyant. Their answer speaks to some scientific work others have done to understand the vesicle-encoding operon, research that has shown at least one gene in the operon is a negative regulator. By deleting that gene, the Melbourne team thinks they might make their cells even more buoyant. If you and your team were the Melbourne team, what would you do with this information?

First let's review one technical advance that opens a number of options for you, namely DNA synthesis. Then as a class we'll consider some options--weighing these (or others) in terms of their associated cost (both time and money).

• Use the entire gas vesicle operon to get the basic Coliform system working then tweak the system later to improve it.
• Wait to assemble your system until you can perform experiments to know more about each gene in the operon.
• Divide the team in half, with some launching into the project with the DNA as is, and others studying it and refining it.
• Spend one week in the library to read all you can about these vesicles and then decide.
• Place a DNA synthesis order for the full operon (6 kilobases) as well as every single gene knockout and double gene knockout.

Mapping These Ideas to your Project

Now it's time to look at the list of devices you have identified as part of your project (some of you may have a full list of needed devices and some of you will have only a partial list, in which case you'll have to consider these ideas now and then revisit them when your device list is complete). What might factor into the cost and time of assembling the devices into your working system? Do you know all you need to know about how they work? Are there easy ways to find out more? Do the devices already exist or will you have to make them yourself? You might want to make a chart that lists your degree of confidence in each device, where confidence is tempered by its cost/time/source/description and perhaps safety/security concerns...something we will return to next week.

Generate a list or table that might be useful as part of your Tech Spec Review next week.

Part 3: Project Work Time

Let's get busy working on the details of these projects!

Back to Top

Lecture 15: Hypothesis-Driven Engineering

"Faith is a poor substitute for reason"

Thomas Jefferson

As you hone in on the details of your projects, your team should plan ways to validate the system's operation and ways to learn from its glitches. We have two quick challenges for you today. The first illustrates that even the "best" answers you can offer that are consistent with all available data remain tentative, that the answer is either strengthened or revised by additional data and that all interpretations are subject to personal biases, human values and the various ways we all think about the world. The second challenge puts you midstream in a flawed design and requires that you consider the modes of failure to debug/troubleshoot the problem.

We will spend only 20 minutes on these challenges and then you and your team can use the rest of today's lecture time to prepare for next week's Tech Spec Review

Challenge 1: The Check's in the Mail

This challenge is adapted from Judy Loundagin's lesson for the Evolution and Nature of Science Institutes.

1. One member of your team should serve as scribe (with notebook sheet to be provided). Another should be spokesperson (see item 7, below).
2. Each team should get one envelope that is filled with fictional checks. Do not look at the checks yet. All envelopes have the same checks.
3. Remove and examine 4 checks only.
4. Discuss a plausible scenario which involves those checks.
5. Once your group has agreed on a reasonable scenario that accounts for the checks, and the scribe has written it down, then you can draw 4 more checks from the envelope. As tempting as they are, the unchosen checks must stay in the envelope, unexamined.
6. Reconsider your initial scenario to include the information you can glean from all 8 of the checks.
7. We will take 1 minute to hear from each team. The spokesperson should detail
   • the content of the first 4 checks,
   • the way your team considered their content and
   • the initial conclusion you drew
   • the details of the next 4 checks and
   • the revisions you made to the scenario to accommodate the information.

Finally, the spokesperson should say what kind of check they would expect to see in the envelope if their scenario is correct or what kind of check would blow their ideas out of the water and demand a full re-write of their explanation.

Challenge 2: Soap Stress

Stresses on a cube: compressional stress (left), tensional stress (center), shear stress (right). (Images courtesy of NASA JPL.)

 

This challenge is adapted from one described at teachengineering.org. We will skip the preliminary descriptions of plate tectonics and just remind you of three stresses that give rise to deformation: compression, tension and shearing forces.

Soap stress in action.

 

1. Begin by looking at how the packaged soap is breaking during shipment from the factory to the distributor (a sample of the broken soap will be available for you to look at). Decide as a team which kind of stress could be leading to this kind of damage. Pick only one kind (i.e. not a combination of tension and shear) and rate your confidence in that choice on a scale of 1-10 (1 = we had to pick something so we picked this, 10 = I'd bet my house on it)
2. Now start counting costs to analyze and fix what you believe to be the failure mode.
   • if you'd like to stress an unbroken soap bar, each bar costs $1
   • if you'd like to use paper to wrap each bar of soap, each sheet of paper costs $0.01
   • if you'd like to use a small piece of cardboard to line each bar of soap, each piece of cardboard costs $0.05
   • if you'd like to use larger sheets of cardboard to line each 12 pack of soap, each large sheet costs $0.50

In 5 minutes, your team will be asked

• which of the three stresses you believe could be breaking the bars of soap
• how confident you are with that choice
• what you'd propose as the best way to fix the problem
• how much you spent to arrive at that recommendation and what your proposed solution will cost
• and finally if you are more or less confident in the source of stress that's breaking the soapbars after this quick round of failure analysis, and debugging.

Be sure to wash your hands before you touch your eyes if you've been breaking soap to test it.

Mapping These Challenges to your Project

There is no such thing as either complete knowledge or flawless design. And if you believe, as Henry Petroski does, that "...the central goal of engineering is still to obviate failure, and thus it is critical to identify exactly how a structure may fail,"¹ then you and your team will dedicate effort

• to collecting relevant data that validates or disproves the ideas in your own project; and
• to anticipating failure modes so debugging your design is trivial rather than backbreaking.

These ideas of validation and debugging should be included in your Tech Spec Review, at least a first go at them.

Back to Top

¹ Petroski, Henry. To Engineer Is Human: The Role of Failure in Successful Design. New York, NY: Vintage, 1992, p. 195. ISBN: 9780679734161. [Preview in Google Books]

< Previous Week | Lecture and Studio Notes Index | Next Week>