At a glance
Teams · launched Unit 4, Day 2 and due Unit 4, Day 3 · a working program your team did not write, one bug to fix and one feature to add, without breaking anything that already worked
What you are making
Nothing. That is the point.
Your team is handed a program somebody else wrote — another team’s project from a previous semester, or one I have prepared with its own habits and its own history. It works. It has users. It has at least one bug that its authors never noticed and at least one thing it does not do that somebody now needs.
You will read it, run it, test it, and change it. Two changes only:
- One fix. A reported bug, described the way real bugs are reported: by a person, in a sentence, with no line numbers.
- One extension. A small feature the current owner asked for.
The assessed skill is not the change. It is that everything that worked before still works afterwards, and that you can prove it.
The bug report you are handed
From: the music room
Every Monday the notices print fine. This Monday it stopped
partway through and showed a wall of red text. Nothing printed
for anyone after the cello. Nothing has changed at our end.Here is the wall of red text:
Traceback (most recent call last):
File "/loans/signout.py", line 23, in <module>
main()
~~~~^^
File "/loans/signout.py", line 19, in main
loans = load_loans("loans.csv")
File "/loans/signout.py", line 14, in load_loans
loans.append(Loan(item, borrower, int(days)))
~~~^^^^^^
ValueError: invalid literal for int() with base 10: ''Read it from the bottom up. The last line is what went wrong; the lines above it are how the program got there. Notice what it tells you and what it does not: it names a file, a line, and a value that could not be converted — and it says nothing at all about why a row of the data file has an empty days field, or what the program should do about it. That decision is yours, and it is a design decision, not a syntax fix. Reading a Traceback in Someone Else’s Code is the method.
The order of work
Do not skip step three. Every team wants to.
- Run it on ordinary input, then on strange input. Write down what it does, in three sentences, before you have an opinion about it.
- Find the entry point, name the nouns, and follow exactly one path end to end. Ignore everything else on purpose. The method is Reading Somebody Else’s Code.
- Characterise it with tests, before you change a line. Write tests that capture what the program currently does correctly — not what you think it should do. These are the tests that will tell you, tomorrow, whether your fix broke something quiet. See Writing Tests and Testing and Regression.
- Reproduce the bug with a test that fails. Only now do you know what you are fixing.
- Fix it, in the smallest change that makes the failing test pass and leaves the characterisation tests green.
- Add the extension, on its own branch, with its own tests.
- Leave a note. Whatever you worked out about this program that was not written down anywhere — write it down. A comment, a line in the README, an entry in the journal. You are the only people who will ever have that understanding for free.
Read charitably
You will find code you would not have written. Before you rewrite it, assume the author had a reason you have not discovered yet: a constraint, a bug they were working around, a partner who insisted. Ask what would break if you removed it. Sometimes the answer is “nothing”, and you have improved the program. Sometimes the answer arrives three weeks later at the worst possible moment.
You are not marked on how much of this program you replaced. You are marked on how little you had to.
What you hand in
- The changed program, with your two changes and nothing else.
- Your characterisation tests, written before the changes.
- The failing test that reproduced the bug, now passing.
- A change log, half a page, written by each of you separately: what the bug actually was, what you changed, why you chose that fix over the alternatives, and what you deliberately did not touch. The program is the team’s; this is the piece that is yours, and it is read under your own name.
- The note you left for the next team, quoted in your submission.
Milestones
- Unit 4, Day 2 — it runs on your machines, and every member can say in one sentence what the program does.
- Unit 4, Day 2, in the sprint period — characterisation tests written, and the bug reproduced by a failing test.
- Unit 4, Day 3, last twenty minutes — submitted. Fix, extension, tests green, a change log from each of you, and the note. The finishing happens here, in class, not the night before.
How this is assessed
Per How Marks Work, the reading is assessed as heavily as the writing. A team that fixes the bug by rewriting half the file has demonstrated less than a team that fixed it in four lines and can explain the four lines they did not touch.
Your Code Journal wants the honest entry: the moment you understood what the original author was doing, and how long it took. Compare that number with how long the author would have needed. That difference is the real subject of Who Maintains This, and it is about to be true of your own project.
Success criteria
| Quality | What it looks like in your submission |
|---|---|
| Read before changed | Three-sentence description, written before edits |
| Characterised first | Tests capturing existing behaviour, dated earlier |
| Bug reproduced | A test that failed, then passed, unchanged otherwise |
| Smallest sufficient fix | Change log defends what you did not touch |
| Nothing quiet broken | All characterisation tests still green |
| Extension isolated | Own branch, own tests, honest scope |
| A note left behind | Something the next team gets for free |
| Yours, under your name | Your own commits, and your own change log |
Reflect
In your journal: what did this program’s author know that they never wrote down, and how did you find it out? Then turn it around — name one thing about your team’s project that only one of you currently knows, and put a date on when it gets written down.
If the program is genuinely awful
Some of them are. Inheriting a badly written program is not a punishment and it is not a trap: it is the ordinary condition of professional work, and the skill of staying useful inside it is worth more than any amount of writing greenfield code. Two rules keep you sane. Do not rewrite what you have not tested — a rewrite with no characterisation tests is a new program wearing the old one’s name, and its bugs are now yours. Write the change log as you go, not at the end; the reasoning that makes your fix defensible is obvious to you at 2pm and gone by 4pm. If you truly cannot make progress by the end of the launch class, come to me and we will read the entry point together.
Curriculum connection
A2.3
demonstrate the ability to modify existing modular program code to enhance the functionality of a program.
Link to original
A4.1
work independently, using support documentation (e.g., IDE Help, tutorials, websites, user manuals), to resolve syntax issues during software development;
Link to original
A4.2
develop and implement a formal testing plan (e.g., unit testing, integration testing, regression testing) for a software project to ensure program correctness;
Link to original
B1.2
develop the software product according to the project plan (i.e., ensure that the software meets end user needs, functions as intended, and can be produced within quality standards, budget, and timelines);
Link to original
B1.3
produce the software according to specifications (i.e., code, test, deploy), and create user documentation and training materials;
Link to original
B2.2
demonstrate the ability to meet project goals and deadlines by managing individual time during a group project;
Link to original