Skip to the content.

✅ Quiz 07 — From Idea to App

Answer in your head or on paper, then open the fold to check. No grades, no timer — this is for you.


1. What is the software development lifecycle (SDLC), in one sentence?

Show answer It's the journey every piece of software takes: figuring out what users need (requirements), planning it (design), building it, testing it, releasing it, and then maintaining it — usually forever.

2. A friend says: “As a commuter, I want to save my usual route, so that I don’t have to type it every morning.” What is this sentence called, and which SDLC stage does it belong to?

Show answer It's a **user story**, and it belongs to the **requirements** stage — writing down what the software must do for people, before anyone designs or builds it.

3. Which of these is a user story written correctly? a) “The app will store rider data in the cloud.” b) “As a rider, I want to see my driver on a map, so that I know when to walk outside.” c) “Add a map screen with a blue location dot.”

Show answer **b).** A user story describes a *person's need and why*, with no technology decisions. Option (a) is a technical decision and (c) is a design instruction — both come later.

4. What’s the difference between a wireframe and a design doc?

Show answer A **wireframe** is a rough sketch of what a *screen* will look like — boxes for buttons and text. A **design doc** is a written plan for how the software will work on the *inside* — its major pieces and how they fit together. One is for the outside, one for the inside.

5. Your cousin texts you: “Our team deploys tomorrow.” What is about to happen, in plain words?

Show answer Their new software (or new version) is about to be moved from the team's computers onto the real computers where actual users can use it. Tomorrow, it goes live.

6. In the lesson, the house-building analogy for software “honestly breaks” at one particular stage. Which stage, and what’s the better analogy?

Show answer **Maintenance.** A finished house mostly stays built, but software never stops changing — users want new features, and the world around it (phones, browsers, competitors) keeps shifting. The better analogy is **gardening**: you plant it, then tend it forever. Most of the total effort on successful software happens *after* release.

7. Describe waterfall and agile using the cooking analogy from the lesson.

Show answer **Waterfall** is cooking a 10-course banquet from a menu fixed months in advance — everything planned, cooked, and served at once, with no way to adjust if the guests hate seafood. **Agile** is tasting-and-adjusting as you cook: serve one dish, get reactions, adjust the next dish. In software, those adjustment rounds are called **sprints**, usually two weeks each.

8. Why did the software industry largely move from waterfall to agile?

Show answer Because people are bad at knowing exactly what they want until they can touch it. Under waterfall, teams spent months building precisely what was requested, only to discover it wasn't what was needed. Agile shortens the loop: build something small, learn from real users, adjust — so mistakes cost weeks instead of years.

9. Your friend’s grand vision is “a car”. Following the MVP idea, what should their version 1 be — a wheel, or a skateboard — and why?

Show answer A **skateboard**. It's the smallest thing that serves the *whole purpose* (moving a person from A to B), so real users can use it and teach you things immediately. A wheel is a *piece* of the final product but useless on its own — while you build the rest, you learn nothing. An MVP is the whole idea in miniature, not a fraction of the features.

10. Why are software projects so often late, even with skilled, honest teams? Use the renovation analogy.

Show answer Because of **unknown unknowns** — problems you couldn't have listed in advance. Like renovating an old house: you quote two weeks for the bathroom, then open the wall and find ancient wiring and an unmapped pipe. The information needed for an accurate estimate didn't exist until the work started. Software is full of such walls, and every project is being built for the first time.

11. True or false: once an app is released and working well, the engineering team can move on to other things.

Show answer **False.** Released software needs constant maintenance: fixing newly discovered bugs, keeping up with changing phones and browsers, and adding what users ask for. Over a successful product's lifetime, most engineering effort is spent after release. That's why "done" software still employs engineers — and why your apps update every week.

12. 🗣️ Explain it to a friend

Imagine a friend says: “My brother-in-law is a software engineer and his project has been ‘almost done’ for a year. Is he bad at his job?”

Explain to them, in under a minute and without using any jargon, why software is so hard to estimate — and why “almost done” software still needs work after launch.

One possible answer "Probably not! Estimating software is like quoting a renovation on an old house — you don't know what's behind the wall until you open it, and software is full of walls. Every project is being built for the first time, so surprises are guaranteed, not a sign of laziness. And here's the twist: software is never really 'done' the way a house is. It's more like a garden — once it's live, users ask for new things, phones change, problems surface, and someone has to keep tending it. His project will be 'almost done' forever, and that's actually normal."