A plan is not an order of work

The document from Lesson 2.5 says what Recall is. It does not say what to build first.

If you hand the whole document to an agent and say “build this”, you get a large amount of
code all at once. Some of it will be wrong. You will not know which part, because you have
no working version to compare against.

The rule for splitting work

Each step should end with something you can run and check.

Not “something that is finished”. Something you can look at and say yes or no.

This is why you do not build all the database tables first, then all the pages. That order
gives you nothing to check until the very end. Instead build one thin slice that goes all
the way from the screen to the stored data, then the next slice.

Recall, in steps

Step 1  An empty project that starts and shows "Recall" in the browser.
        Check: it runs, page loads.

Step 2  A cards table in the database, and a script that adds one card by hand.
        Check: the card is in the database file.

Step 3  A page listing all cards.
        Check: the card from step 2 appears on screen.

Step 4  A form to add a card.
        Check: add a card in the browser, it appears in the list.

Step 5  Delete and edit a card.
        Check: both work from the browser.

Step 6  The scheduling function, alone, with tests. No screen yet.
        Check: the tests cover every example from the plan, and pass.

Step 7  The review page: one card at a time, show answer, three buttons.
        Check: reviewing a card changes its next review date correctly.

Step 8  Show only cards due today or earlier, oldest first.
        Check: a card due tomorrow does not appear. An overdue card does.

Step 9  The empty state message.
        Check: with no due cards, the message appears.

Step 10 The summary numbers.
        Check: the counts match what is in the database.

Why step 6 sits where it does

The scheduling function is built alone, with tests, before any screen uses it.

This is deliberate. It is the only genuinely tricky logic in the app. If it is mixed into a
page, a mistake in it looks like a page problem and you will hunt in the wrong place for an
hour.

Built alone, it is a function with numbers going in and numbers coming out. Wrong answers
have nowhere to hide.

You will meet this idea again in Module 5. Pull the hard part out where you can check it.

A warning about eager agents

An agent handed step 3 will often do steps 3, 4 and 5 as well. It is being helpful.

Do not accept this. Not because extra work is bad, but because you are now reviewing three
changes at once instead of one, and your ability to spot a mistake drops sharply with size.

Module 4 teaches you exactly how to stop it. For now, notice that the habit of small steps
is yours to keep, not the tool’s.

Try this before the next lesson

  1. Cover the step list. Write your own from the plan. Compare.
  2. For each of your steps, write the one thing you would look at to check it. If you cannot
    name one, the step is too big or too vague.
  3. Which step do you think will go wrong first? Write down your guess and keep it.
PreviousNext