Is this really what Problem Solving means in Computer Science?


I am sorry put a spanner in the works but I have to criticize the ideas being presented in this unit as, ‘Problem Solving’ in Computer Science.

As a scientist this looks very much like teaching the ‘scientific method’ rather than being to do with what is called ‘problem solving’ in computer science. (As in the use of the term, ‘abstraction’, the meaning of words in other walks-of-life is quite different to the meaning adopted in CS. )

I have to ask how finding out how to build a boat actually relates to the ‘problem solving’ that is required in computer science?

Problem solving in computer science does not mean the same as in maths or science i.e. it is not, ‘How do I build the best boat?’ or ‘How do I add 2 plus 2 and give the answer?’ The problems that computer scientists solve are ones that the humans already know how to do. Drive a car, make an invoice, open a door when someone arrives. Work out what the weather will be like tomorrow.

Problem solving in CS is taking a known problem, e.g. building a boat or adding two numbers together and then ‘solving’ it by creating a valid set of instructions that the computer can follow in order to build that boat.

The problem = the job to be done, something that we already know how to do but would like a computer to perform. most of the time there is nothing remarkable about the job/problem to be solved - it is just that we want a machine to do it for nothing, over and again and in double-quick time.

Solving = analyse that problem i.e. break it down into its parts, find the algorithm that describes the flow of control and then write a valid set of correctly structured instructions that the machine can follow.

So ‘problem solving’ in computer science does not mean finding out how best to do the task - it simply means finding out how to automate the task for the dumb machine.

I would suggest that a more useful formulation of the algorithm for problem solving in computer science is:

  1. Do the task yourself so that you can see what it is made of
  2. Write down the steps you took
  3. Look for data inputs and information outputs
    4a. Draw a flowchart / structure diagram and as you do so
    4b. Apply abstraction, grouping the parts as sub-problems, so that you don’t get overwhelmed with too much stuff.
  4. Translate this algorithm into whatever code language you like.

There is a tendency to think that computers are like human brains and that we are learning how to do really clever things with computers - like doing science or having insight. That is not the case. We are learning how to get computers to do really simple things that we can do. That is plenty hard enough! Okay, we know that they can be made to do really complex things like flying a plane or predicting the weather but it wasn’t that computers were used to ‘solve’ those problems - they just do the cleverly worked out steps found by human brains. So, I would suggest that kids need to start by finding success in getting the machine to do really simple things - solving simple problems. How do I make the best boat? Whooa! Hold on there, that really is rocket science.

Try starting with, ‘How do you put on your shoes and socks?’ In this you will find most of the necessary stages of sequence, selection, repetition, data input (which shoes?), outputs (actions in this case) and abstraction (picking up a sock is made from many steps that are best dealt with as a sub-problem in its own right.

Okay, that then becomes too hard a problem for a kid to solve completely - there is far too much abstraction (layering) to get the robot to complete all of that.

So, go with, ‘How do I get the machine to find out if a pupil can add two numbers together correctly?’ There is enough in that to keep a class busy for several lessons. I’ve just done it. And then, 3 goes etc.

Kind regards

Mark Thomas
Tunbridge Wells, UK

P.S. Note the misuse of ‘abstraction’ in your lesson plan - abstraction, as you rightly describe elsewhere, is about the use of subroutines to keep code intellectually manageable. It is not about losing/neglecting stuff as is so often erroneously stated.


Hi Mark,

Thanks so much for sharing your thoughts. This lesson is intended to introduce a general problem solving process, so you’re right that it’s not specific to what we might do in computer science. As you look at later lessons in the unit, you will see more of a focus on what it means to problem solve in the context of computing.

I can’t find the reference abstraction in this lesson plan, so I’m having trouble addressing your concern about the definition. I don’t think that it’s ever described as losing anything. If you can point me to where you saw that, we can take a look.



Hi Elizabeth

Thank you for your reply. I am sorry but I would have to dissent from the view that this is on target for problem solving as that applies to Computer Science. I am also sorry, I cannot now find that reference to abstraction myself. When I have a little more time I will have another search.




I can understand your concerns from a purely academic point of view. However, as first and foremost a software engineer with over 18yrs experience in the industry, including Mobile Applications and Enterprise Web Applications, I believe that this lesson was very spot on with regards on how to approach solving tasks that I regularly work on.

Very often software developers, and engineers, are asked to deliver solutions to problem without really understanding the full scope of the problem. In a Scrum Environment, those tasks are typically assigned as Spikes. Basically the complete state for those tasks is having an idea of how to properly solve the problem later, versus actually solving the problem. In most cases the tasks are resolved a lot like the boat challenge. The developer, or team, will draw on past successes (or a quick search on the internet) and attempt to implement a prototype code solution. After the prototype is ready it is tested for feasibility (much like putting the pennies into the boat). An analysis of the test results are then done to determine if the prototype is worth pursing or if another approach should be done.

Admittedly, in practice most software solutions rarely get the benefit of multiple runs. If the first approach solves the majority of the issues without presenting too many hurdles it is often persuaded blinding to completion or until it finally proves unattainable.