Getting it working / problem decomposition

Until you're use to programming, issues getting the interpreter or IDE to work can be a frustrating fall at the first hurdle. However, the way to handle software not working is instructive of a broader theme in debugging, and computational thinking more generally: decomposition.

In decomposition during debugging, we try to break down a problem into component parts, and test each component separately to see if it is causing the problem. During development, we also generally decompose problems into their component parts, writing algorithms to work up each part separately, testing the program works to some degree after each bit of code. Sometimes this is as simple as writing and testing each statement in turn, but often it means getting an overall framework working in a basic sense, and then adding detail in a step at a time.

The two areas of decomposition are not unrelated: if you break down writing a program into small parts, and do them one at a time, you are less likely to create bugs, or, at worse, you'll know where they are, making decomposition during bug hunting easier.

Let's look at a simple example.

1. This page
2. The problem <-- next
3. Decomposing the problem
4. Testing the parts
5. Solving the issues 1
6. Solving the issues 2
7. Final points