🔉 🤘 🕺 🎛 🤘 💃 💿

Let's DJ Folks!

The Marshmallow Challenge

🌟 The Marshmallow Challenge

A Software Engineering Perspective

Graduate Software Engineering – ICSI 518 / CSIS 410

What Is the Marshmallow Challenge?

A fast-paced team activity where you must:

  • Build the tallest free-standing structure
  • Using:
    • 20 sticks of spaghetti
    • 1 yard of tape
    • 1 yard of string
    • 1 marshmallow
  • Time limit: 18 minutes
  • The marshmallow must be on top

Activity Flow

  1. You have 18 minutes to build.
  2. You must end with the marshmallow on top.
  3. Once time is up → hands off.
  4. We will measure heights and declare a winner.
  5. Do ask questions now if anything is unclear!

Team Setup

  • Groups of 5 students min
  • Assign quick roles:
    • Architect (design strategy)
    • Builder(s)
    • Timekeeper

📏 Recap : Rules

1. The Structure Must Stand on its Own

2. No need to use all materials

3. Time Limit

  • 18 minutes

Ready?


(18-minute timer - YouTube Music)

Stop! Hands Off!

Wrap Up & Measure

  • Is your structure standing?
  • Measure height with the marshmallow on top
  • Record group results

Winners! 👏

🔍 What Typically Happens

Most teams:

  1. Plan heavily
  2. Build once
  3. Add marshmallow at the end
  4. Structure collapses
  5. No time to recover

These are similar to SE failure modes.

Who Usually Wins?

Studies show:
Kindergarteners > Engineers > MBAs

Who Usually Wins?

Studies show:
Kindergarteners > Engineers > MBAs

Kids and kindergarten tend to outsmart professionals.

  • they spend more time prototyping and playing

they spend more time prototyping and playing

  • They prototype early
  • They test the marshmallow’s weight immediately
  • Low ego, low hierarchy
  • Continuous iteration instead of big upfront plans

🎯 Hidden Assumptions

The Marshmallow Challenge exposes critical project assumptions:

  • Initial assumption: Marshmallows are light and easy to support
  • Reality check: Marshmallows are heavier than expected
  • SE parallels: Cost estimates, customer preferences, project timelines

Key Takeaway:

  • Test assumptions early and frequently
  • This drives innovation and prevents late-stage failures

What About Software Engineering?

🔧 SE Insight #1:

Iteration Beats Planning

Marshmallow = integration point
Structure = architecture

Good teams:

  • Build test structures early
  • Integrate continuously
  • Refine design iteratively
  • Embrace failure as signal, not setback

This is Agile, CI/CD, risk-first development.

🔧 SE Insight #2:

Requirements Ambiguity Is Real

“Tallest free-standing structure, marshmallow on top.”

Yet teams still ask:

  1. Can we tape it to the table?
  2. Does it need to stand for 5 seconds?
  3. Can we break spaghetti?
  4. Are we allowed to anchor with string?

This is real-world SE requirements ambiguity.

🔧 SE Insight #3:

Architectural Risk Management

  • Marshmallow weight = highest risk component
    • Focus on high value features first...
    • If you make Login first... your architecture will be shaped around that.
  • Putting it on last = late integration → catastrophic failure
  • Testing early = risk mitigation → informed design
  • Identify Hidden Assumptions early

🔧 SE Insight #4:

Team Dynamics Under Pressure

The challenge exposes:

  • Collaboration patterns
  • Conflicting leadership styles
  • Silent vs dominant team members
  • Sunk-cost bias (“don’t change the design!”)

This leads into Brooks' Law and Conway’s Law.

📚 Brooks’ Law

“Adding manpower to a late software project makes it later.”

-- The Mythical Man-Month, 1975

Brooks' Law - Wikipedia
Nice Article

📚 Brooks’ Law

“Adding manpower to a late software project makes it later.”

In Software Engineering:

  1. New people need time to ramp up
  2. Communication overhead increases
  3. Coordination complexity grows
  4. Diminishing returns on added resources

Marshmallow Challenge:

  1. Too Many people giving directions
  2. High coordination overhead
  3. Late-stage changes slow everything
  4. Communication > construction

📚 Brooks’ Law

  • Avoid late additions
  • Keep teams small and focused
  • Good segmentation minimizes the communication overhead.
    • Design Patterns simplify distribution of work.
  • Architecture patterns and modular design help manage complexity.

📚 Conway’s Law

“Organizations design systems that mirror their communication structures.”

-- Melvin E. Conway, 1968

📚 Conway’s Law

“Organizations design systems that mirror their communication structures.”

Notice this? :

  • If the group splits into sub-teams without coordination → mismatched structure
  • If one dominant voice designs the plan → structure reflects that hierarchy
  • Communication patterns shape the structure more than technical constraints

📚 Conway’s Law

“Organizations design systems that mirror their communication structures.”

In Software Engineering:

  1. Team structure influences system architecture
  2. Communication pathways shape design decisions
  3. Cross-functional teams lead to integrated solutions
  4. Organizational silos create fragmented systems

Marshmallow Challenge:

  1. Team communication patterns shape the structure
  2. Dominant voices lead to rigid designs
  3. Collaborative teams produce cohesive structures
  4. Fragmented communication leads to unstable designs

🔧 SE Insight #5:

Integration Timing = Success or Failure

Teams that succeed:

  1. Start with marshmallow
  2. Build around constraints
  3. Iterate several versions

Teams that fail:

  1. Integrate last
  2. Design large, fragile plans
  3. Never test the riskiest part early

Exactly like poorly run software projects.
Hint Hint... CI/CD + Agile + Automated Testing

Summary

The Marshmallow Challenge is a lesson about:

  • Iteration > speculation
  • Prototyping > planning
  • Team Dynamics
  • Identify Hidden Assumptions
  • Early + continuous integration
  • Architecture shaped by human dynamics
  • Brooks' Law & Conway's Law in action
Marshmello challenge is adopted from original challenge popularized by Tom Wujec, Generative AI was used to help format and edit some slides

SLIDE 5

SLIDE 6

SLIDE 12

SLIDE 13

SLIDE 15

SLIDE 17