Is this really what Problem Solving means in Computer Science?


#1

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.


#2

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.

Thanks,
Elizabeth


#3

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.

Mark


#4

Mark,

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.

v/r
Patrick


#5

Hello Mark,

Your letter reflects a “teach to the test” style mind set whilst this course seems designed to do the opposite. The truly fantastic thing about this course is that it motivates and inspires as much as it teaches core skills and competencies. Many of the children I taught last year were highly unwilling to take the class and all are now asking for more. Enjoyment is something that should not be underestimated. This first lesson sets the scene for the year in a way that your logic based class would not. Breaking down the process into logical steps starts in lesson 2.

As a user of software of many different kinds I also disagree with your fundamental premise that the job to be done is one we already know how to do. Issues with software often arise because the problem was not correctly defined at the start; all cases were not considered; the code was incorrectly structured etc. For example, SNCF trains allow you to buy tickets online for collection at station ticket machines. As a security measure they make you put the credit card with which you made the purchase into the ticket machine to persuade it to print the ticket. Fool proof idea?? Er, many people use virtual one-use e-cards for online purchases. Anyone doing this cannot get their ticket, even from a ticket office. They have lost their money. Other people may use their credit card to buy a ticket for someone else - even a child who is stranded in a different town… The execution of the code is fine. The thought processes behind it inadequate.

This first course does teach children to program. It will require them to use logic. I really like this non-technical chapter for its emphasis on planning.


#6

Thank you for all of your replies to my post. Sorry, but you are all missing the point. I would suggest that kind of boaty ‘problem solving’ may hit developers on top of everything else. However, for novices, trying to work out how to code, they do not need to attempt to find the way to solve a problem in the sense of the boat. They don’t need rocket science. They do not need that on top of learning coding - learning coding is quite enough of a challenge.

The ‘problem solving’ they need to learn is how to find the algorithm in the problem domain so that they can then write correctly structured code. Not design an algorithm as some say but to find it. Socks first, then shoes with the left shoe on the left foot. That algorithm exists - it belongs to the process. You can then do the process/task yourself or have a machine do it following your correctly structured code. Problem solved.

We are not in the business of solving the problem for SNCF - we are showing kids how to get started, how to ‘solve’ simple problems. My pupils have just gained top grades in the English system. However, before I realised what problem solving really meant I saw some of them failing. It wasn’t code that was the problem - it was finding the algorithm, drawing it (flowchart or Jackson) and then translating that into code that was the block. So I have worked on finding those algorithms - this is how the problems are solved for these beginners to this craft.

There again the naturals, the ‘hackers’ if you will, could just do that in their heads without bothering to formalise the algorithm as a flowchart - I suspect that that is what many professionals can do and so think that this is what anyone should be able to do. They can’t, they haven’t got that exceptional sort of brain. They need to formally find the algorithms before they start coding - and that is quite enough for them to do.


#8

Hi Mark,

Thanks for sharing your perspective. For me, CS is more than just about coding, so from my perspective learning to code is isn’t enough for the students.

In my experience, students have been able to rise to the challenge of really understanding and defining the problems that they are trying to solve before staring to plan how they might address them. Rather than being something extra, it was a key part of the process that helped them to understand the context and impact of their solutions. This was really important for me, because it lay a good foundation for them to use CS in creative ways that were relevant to their lives. Even beginners were able to address these sorts of complex “expert” problems with a solid foundation in structured problem solving.

Regards,
Elizabeth