Improving

One-sentence summary

Improving means making a working project better in small steps, using tests and feedback — in each step you plan, do, test and learn, and you stop when the project is "good enough."

Why does it matter?

You closed the bugs in your bug log, and your project now works. Your night light turns on in the dark and turns off when it should. This is exactly where most people fall into one of two traps.

Some say, "It works, I'm done," and stop. But "it works" and "it works well" are not the same thing. The lamp turns on, but maybe it turns on a second too late, or it flickers on and off during the day. These are not bugs; they are just things that could be better.

Others do the opposite: they improve endlessly, add a new feature every day, and the project is never finished. Presentation day arrives and there is nothing working, because everything is stuck in a "half-done but better" state.

This lesson teaches the middle ground: making a project better on purpose, in small and tested steps, but being able to say "this is enough" at some point. Most of what engineers and programmers do is exactly this. The first version is rarely the best version; the real work is improving it step by step.

The improvement cycle: Plan – Do – Test – Learn

Improving is not making random changes. It follows a cycle. This cycle has four steps, and each loop carries you a little further:

        ┌──────────────┐
        │    PLAN      │  What will I change, and why?
        └──────┬───────┘
               ↓
        ┌──────────────┐
        │     DO       │  Make just that one change.
        └──────┬───────┘
               ↓
        ┌──────────────┐
        │    TEST      │  Did the change work?
        └──────┬───────┘
               ↓
        ┌──────────────┐
        │    LEARN     │  What did I learn? What's next?
        └──────┬───────┘
               ↓
        (the cycle starts again)

Plan

First pick one thing. Set a concrete goal like "the night light reacts too late," and write down why you will change it. Do not try to change five things at once; then you cannot tell which one worked.

Do

Make the single change you planned. Lower the light threshold a little, or shorten the sensor's reading interval. Touch only that small part of the code or circuit.

Test

Run the test scenarios from the previous module again. Did the change work? Also check: could a new bug have appeared? While improving, it is very common to fix one place and break another.

Learn

Judge the result. If it worked, keep the change and move to the next improvement. If it did not work, undo it and think about why. Every loop makes both the project and you a little better.

Small steps and the "second version" idea

Why small steps?

Imagine you built a paper plane. It does not fly well. If you enlarge the wings, weight the nose and bend the tail all at once, and the plane improves, you will never know which change did it. But if you try them one at a time, you see the effect of each change. Projects are the same: small, single steps are both testable and reversible.

Small steps have another benefit: after each step you still have a working project. If you attempt a big change and get stuck halfway, you are left with something that does not work. With small steps, you always have a version you can point to and say, "this one works."

The "second version" idea

Professionals do not try to make a project perfect in one go. First they release a working first version. Then they use it, test it, collect feedback, and use what they learned to build a second version.

The same applies to you. The first version of your night light only did "turn on in the dark, turn off in the light." In the second version you could add:

• The light fades on and off slowly, instead of snapping.
• A very brief shadow from your hand does not make it blink (add a small delay).
• A button that turns the lamp fully off.

Notice that none of these are "bug fixes." They are all about making a working thing better. The second-version idea tells you this: finish the first version, then build on top of it with what you learned.

How to collect feedback

The best improvement ideas often come not from you, but from *someone other than you* trying the project. Because you know the project, you already know how to use it. Someone else does the thing you never thought of.

Have a friend test your line-following robot. Questions like "Why did it slow down there?" or "What is this button for?" give you new improvement ideas. When you ask for feedback, ask open questions: instead of "Do you like it?", ask "What did you not understand?" or "What was the most annoying part?" Those questions bring more useful answers.

How far should you improve? "Good enough"

The hardest part of improving is knowing when to *stop*. You can improve any project forever, but at some point each new thing you add gives very little benefit and takes a lot of time. That point is called "good enough."

"Good enough" is not laziness. It means remembering the project's purpose and checking whether it meets that purpose. If the night light's purpose is to guide you in the dark, and it does that reliably, then adjusting the light's colour is a "nice to have" extra.

To sort improvement ideas by priority, you can use a simple table:

Finish the "must have" row first. If you have time left, move to "nice to have." The "optional" row only gets its turn if everything else is ready. If a presentation or a deadline is near, you can safely set the "optional" ideas aside.

You can test whether a project is "good enough" with this short checklist:

IS IT GOOD ENOUGH? CHECKLIST
[ ] Does the project fulfil its main purpose?
[ ] Does it pass all the test scenarios?
[ ] Is there any serious bug still open (unclosed)?
[ ] Can someone else use it without help?
[ ] Are the remaining ideas only "optional" ones?

If the first four boxes are checked and the last line is "yes,"
the project is probably good enough. You can stop.

Mini practice

Pick one of your own projects (or the project you used in your bug log) and prepare an improvement list. The goal is to organise the scattered "I could also add this" ideas in your head by priority.

Copy the template below and fill it in:

PROJECT: ____________________
PURPOSE (one sentence): ____________________

IMPROVEMENT LIST
No | Idea                      | Priority        | Status
---|---------------------------|-----------------|--------
1  |                           | Must have       | Planned
2  |                           | Nice to have    | Planned
3  |                           | Optional        | Planned

PRIORITY: Must have / Nice to have / Optional
STATUS: Planned / Doing / Tested / Done

RULE: Before you mark an idea "Done," check it with a test scenario.

Then run the cycle for a single loop: pick the highest-priority idea (Plan), make only that change (Do), run the test scenarios (Test), and note the result in one sentence (Learn). When a loop is finished, notice how little you changed and how much you learned.

Common mistakes

Changing too many things at once

If you change five things and the project improves, you cannot tell which one worked. If it breaks, you cannot find the reason. Make a single change per loop.

Saying "I improved it" without testing

Making a change does not mean the project is better. Maybe you fixed one place and broke another. After every change, run the test scenarios again.

Never stopping

You can add features to any project forever. If you lose sight of the purpose and fiddle with decorations, the real work is never finished. Use the "good enough" checklist and stop in time.

Losing the working version

If you attempt a big change and break the working state, you may have nowhere to go back to. Move in small steps so that you always have a working version in hand.

Improving only for your own use

Because you know the project, everything is clear to you. If you never have someone else test it, you will never notice the places that are obvious to you but confusing to others.

Safety note

While improving, you will touch the hardware again and again: changing cables, removing and refitting resistors, re-tuning motors. Each time, cut the power first, then touch. Ask an adult for help when working with parts like hot surfaces, batteries and motors. Also, when someone else tests your project, ask for and give feedback kindly: the goal is to critique the project, not the person. A "this part didn't work" from someone is not an insult — it is a free improvement tip.

Lesson summary

• Improving means making a working project better in small steps, using tests and feedback.
• Improving follows a cycle: Plan, Do, Test, Learn — and the loop starts again.
• Make a single change per loop, so you can see what worked and undo it if needed.
• Release a working first version, then build a second version with what you learned.
• Prioritise ideas as "must have / nice to have / optional," and stop when the project is "good enough."

Check questions

1. What are the four steps of the improvement cycle, and in what order?
2. Why are you advised to make only one change per loop?
3. What is the difference between a "first version" and a "second version"? Explain with an example.
4. What questions do you ask to decide a project is "good enough" (give at least three)?
5. Why do the best improvement ideas often come from having someone else test the project?

Answers

1. Plan, Do, Test, Learn. After the Learn step the cycle starts again; each loop carries the project a little further.
2. Because if you change several things at once, you cannot tell which change is responsible for the result, whether it is good or bad. A single change is both testable and reversible.
3. The first version is the first working state that meets the purpose (the night light turns on in the dark and off in the light). The second version is the better state built after using it and collecting feedback (the light fades softly, and brief shadows do not make it flicker).
4. For example: Does the project do its main purpose? Does it pass all the test scenarios? Is any serious bug still open? Can someone else use it without help? Are the remaining ideas only "optional"?
5. Because you know the project, so you already know how to use it and cannot see the problems. Someone else does the thing you never thought of and reveals the places that are obvious to you but confusing to others.

Source and verification note

For “Improving”, verification focuses on whether the relationship between The improvement cycle: Plan – Do – Test – Learn and Test remains consistent across examples. A project page should make a result claim only when it is supported by a real prototype, test record or observation. Numbers such as cost, duration and success rate must be labelled clearly when they are estimates.

Next lesson

Documenting a Project: How do you document your working, good-enough project so that others can understand it and build it again?