CIS 3500

Introduction to
Software Engineering or
"how to JOYFULLY BUILD
with a TEAM"

Prof. Jérémie Lumbroso, Ph.D.

lumbroso@seas.upenn.edu

⚠️➡️ RIGHT NOW, go to https://sli.do

Code #23232325 

LECTURE 5:
Why Process Matters—
How Software Gets Made

Agenda

• HW1's update
• Programming vs Software Engineering
• Discussion on Technical Debt
• Case study on a public service launch
• What is the "Waterfall" production model?
• ThinkPairShare: Have you witnessed a tech failure?

HW1 due last night

Let's take a look!

Programming vs. Software Engineering

• Programming is about producing code that works in the short term.
• Software Engineering is about maintaining and evolving that code over time.
• Key differences:
  1. Time: Short-lived vs. long-lived code.
  2. Scale: Individual developer vs. large, multiperson teams.
  3. Trade-offs: Balancing cost, complexity, and changing requirements.

• “Software engineering is programming integrated over time.” – SE at Google

Technical Debt

A Definition

“Everyday Examples (Daily Life Analogies)”

• Leaky Roof “Patch”

  • Quick Fix: Duct tape over the leak instead of a proper repair.
  • Interest: The damage grows; eventually the entire roof may need replacing.

• Messy Closet “Just Slam the Door”

  • Quick Fix: Throw everything into the closet so the room looks clean.
  • Interest: Finding anything later becomes a nightmare; you spend more time rearranging when you finally clean.

• In Code:

  • Hacking a feature without writing tests → Harder to maintain/test later.
  • Not updating libraries → Security holes or version conflicts in the future.

Key Point: If you keep ignoring technical debt, it can snowball, slow you down, or cause major failures.

In modern production methods, regular refactoring and small increments help keep debt from overwhelming you.

Where do you see technical debt in your daily lives?

Debrief Class Activity

Instances

refers to an actual occurrence of technical debt within software, technology, or organizational systems. These are real-world examples where past shortcuts or outdated systems create a burden that must be addressed in the future.

Analogies

refers to instances where the concept of technical debt is used figuratively to describe inefficiencies, poor planning, or shortcuts in non-technical areas of life, such as personal habits, urban planning, or interpersonal relationships.

Where do you see technical debt in your daily lives?

Path@Penn crashing during advanced registration – This is an actual technical issue caused by poor system design or maintenance.

Cramming for exams instead of studying steadily – This is not technical debt in the software sense but is likened to it because of the short-term gain and long-term cost structure.

Instances

Analogies

35 examples, often involve:

• University Services / Path@Penn / Administration
• Airline or Public Transportation systems
• Outdated websites or software infrastructure
• Personal or corporate codebases with legacy issues

18 examples, often involve:

• Personal productivity, health, or academics (procrastination, messy notes, junk food)
• Home maintenance (leaky faucets)
• Interpersonal relationships
• Larger societal issues (global warming, urban planning)

Instances

Analogies

• mairiair: "With the rise of AI, some people value convenience and will copy code but can arrive at suboptimal solutions with longer runtimes, taking up more space, etc. Overall, the solutions can be suboptimal."
• kimmia: "One example for me was at a clinic I was volunteering at. The software could only differentiate by name and birthdate when searching, often leading to errors given that there are many patients, some even having the same name and birth date. I believe this was due to the age of the software, and many clinicians had other complaints with it being slow. I wonder if this is due mainly to funding challenges, or also because of the difficulty in transitioning to new systems?"
• wualan: "Many platforms to apply for jobs are so poorly constructed and so slow compared to the platforms and systems used by larger and more modern tech companies."
• wesliu: "I think a lot of government organizations have tons of technical debt. Their websites have poor UIs that are never updated. Some companies also have job application landing pages that look very old and are designed very poorly."

• chaelsey: "I see technical debt in my health. Although I often eat junk food or processed meals since it is convenient, it can lead to long-term health impacts."
• sphia: "i can see technical debt in making food without documenting the recipe."
• domchang: "I can see technical debt happening in my normal life in class, when there may be a very confusing question/topic I don't understand, I might skip it or put a simple answer instead of trying to thoroughly understand. This would eventually cause issues during test prep, when I would have to take more time to actually learn it."
• agvarela: "I just dump 90% of my files in downloads, which makes it much harder to sort, find and discard unnecessary ones later."
• wongang: "technical debt can be seen in interpersonal relationships, when difficult conversations are avoided in order to make interactions smoother in the short term. This can lead to greater problems later on when unaddressed issues begin to pile up."
• mwengel: "procrastinating on tasks even though I'll have to rush and be sloppy at the end to meet a deadline"

Healthcare.gov

An American Software Engineering Meltdown Story

Waterfall

Was it ever a good idea??

• At the time, software was often for massive defense or NASA projects—similar to how Henry Ford’s assembly line was a major evolution for car production.

The big drawback: real-world software requirements often aren’t stable or fully known up front.

From Ford to Toyota—Just-in-Time & Lean

• Toyota introduced “just-in-time” production, meaning smaller batches, continuous flow, responding to demand.
• Minimizing inventory and discovering defects early.
• This “lean” approach influenced software—flexibility over rigid large-batch.
• Lean is a big inspiration behind Agile: “build what’s needed now, see feedback, adapt.”

Summary

• Software engineering involves thinking carefully about the evolution of the product and its requirements over time
• Healthcare.gov meltdown: a perfect storm of big-bang Waterfall for a quickly evolving, high-stakes project.
• Waterfall historically made sense in stable, mass-production environments. But modern software often needs continuous iteration.
• Lean/Just-in-Time philosophies → Agile: short cycles, fast feedback, user focus.
• Next lecture: Agile + User Stories – the core tool for capturing real user needs in Agile.

Questions?

Do you understand how waterfall fits in? Its strengths? Weakenesses?

Think-Pair-Share: Agile Rescue

1. Think (2 minute):
   Recall a recent “technical meltdown” or fiasco you’ve experienced or heard about—something that failed or got stuck in a big way (e.g., a university system glitch, a frustrating mobile app, or a well-publicized national-level issue).

2. Pair (3–4 minutes):
   Share your example with a partner. Brainstorm specific steps an “Agile rescue team” might take to stabilize or improve the system quickly—what is one (or two) steps that could have made an improvement?

3. Share your individual answer with your PennKey (1 mins):
   Submit scenario + fix. We’ll collect a couple of examples. Notice how focusing on small, continuous changes can help reverse a major software fiasco and demonstrate why Agile methods thrive in chaotic or fast-changing conditions.

Why This Prepares Us for the Next Lecture:
Much like the Healthcare.gov “tech surge,” Agile’s quick iteration and real-time feedback can rescue struggling projects. Next class, we’ll dive into how these Agile practices work and why they’re so effective.