Refining a Solution

Computational thinking does not stop once the first version of a solution has been designed. Testing that version against the real problem shows where it falls short, and the problem and its solution are then refined so that they deal correctly with what testing revealed. Two common ways to refine a solution are breaking a stubborn part into smaller sub-problems and putting back a detail that testing showed the solution needs.

Decomposing a part further

A program for a school lost-property desk recorded each item handed in and printed how many items arrived each day. The tally section had been treated as a single job, but it kept going wrong: some days were missed and the weekly total never matched the daily ones. The section was still too big to get right, so it was broken down again into smaller sub-problems: count the items for each day, add the daily counts into a weekly total, and print each line of the tally. Each sub-problem could then be solved and tested on its own. Decomposition is not finished after one pass: an awkward part can always be split again.

Putting a detail back

Abstraction keeps only the details the solution needs, but early on you can judge that wrongly. The lost-property program left out where each item was found, because that seemed unrelated to counting items. Testing showed that the desk's report has to say which part of the school the item came from, so the location was added to the data kept. A detail should only be removed if the solution genuinely never needs it.

Testing decides

Testing is what tells you which parts need more work and which details really matter. Refining after testing, rather than guessing in advance, means the finished solution answers the real problem.