How do you best solve a problem is the same question as how do you best write a program. The answer in most cases is top down. This is an extract from my book Trick of the Mind which explores what it is to be a programmer.

The Trick Of The Mind - Programming & ComputationalThought

Buy Now From Amazon

Chapter List

1. The Trick Of The Mind

2. Little Languages
      Extract: Little Languages Arithmetic

3. Big Languages Are Turing Complete

4. The Strange Incident of The Goto Considered Harmful
      Extract: The Goto Considered Harmful

5. On Being Variable  

6. Representation

7. The Loop Zoo
      Extract The Loop Zoo
      Extract Advanced Loops ***NEW!!

8. Modules, Subroutines, Procedures and Functions
      Extract Modular Programming

9. Top-Down Programming 

10. Algorithms
       Extract: Binary Search 

11. The Scientific Method As Debugging 

12. The Object Of It All
       Extract Why Objects 

 <ASIN:1871962722>

<ASIN:B09MDL5J1S>

Subroutines and functions are not just a way to get new commands into a language and so simplify things, they are a fundamental way of solving problems. When faced with a problem, do you go about solving it?For a programmer this is the same question as "how do you create a program?".

If you can build an algorithm to do something then you have a solution to a problem. Programming is not only the process of solving problems, it also presents a number of important tools that help you solve problems. Over the years programmers have looked at what they do and have abstracted a number of principles and a method that used to be called "top-down modular design" is perhaps the most important.

Let's first take a look at the basic idea. Suppose I ask you to write a chess program. If you want this in a wider context I am asking you to solve the problem of chess. In fact, all problems have programs as their solution and all programs solve some problem.

Making A Start

So how do you begin your solution? This is the "blank sheet of paper" challenge. The first word is always the most difficult, and so it is with programming. But not if you take top-down modular programming as your philosophy and approach. All you have to do in this case is call the subroutine that plays chess:

PlayChess();

Problem solved!

Of course, it's a cheat in that no such PlayChess subroutine exists at the moment, but if it did the problem would really be solved. This simple, almost silly, step gets you over the blank page difficulty and gets you started.

It transfers your attention to the task of implementing the PlayChess() subroutine, which isn't tough as long as you keep the same approach in operation:

Subroutine PlayChess()
	setupboard()
	While game in progress
 	 	player1Move()
  		player2Move()
	endgame
	Return

Easy, but does this mean the job is done and the problem solved? Well, no. It is clear we haven't actually got a solution, but we have got closer to one. The point is that we are again using subroutines that don't exist, but this in itself isn't wrong and it does move us towards the solution a layer at a time.

If we continue to implement the procedures that we assume exist at a higher level, at some point we reach a level of specification where it is possible to write some code that actually does something. If you are familiar with the jargon of trees, we reach a “terminal node” in the hierarchy.

This is the whole principle of top-down modular programming.

It is also known as step-wise refinement and divide and conquer.

Stuck

Of course, there are problems with this approach. The most obvious is that you could eventually reach a procedure that you have no idea how to implement. But at least this focuses your mind on why you can't, at the moment, solve the problem. 

Another potential problem is that without a global design in place your modular decomposition might be inefficient, or might not work at all. But given you have something to look at and work over, you might be able to refine your approach and still deliver a solution. In other words you might get stuck, but at least the top-down procedure has focused your mind on the difficulties. It also allows you to identify the easier parts of the problem – you can just ignore these until you get the difficult parts sorted out. You might be stuck, but you have a direction to move in without committing too much time to the design.

In the wider world top-down programming can provide important clues to exactly what the problem is and it highlights what you don’t know. Sometimes when you get stuck implementing a step you’ll suddenly see that earlier steps have led you to a bad place. In this case you may well have to return to the earlier step and restructure things from this point on. This is called backtracking and it is often an unavoidable part of problem solving.

It also has to be admitted that the are times when a top-down approach simply wastes time by sending you off trying to solve a problem that you have no idea how to solve. The playing chess example would probably end this way unless you already had some ideas about how to select good moves. In practice, this would mean either knowing some of the approaches that other people had used in the past or inventing new approaches. You might suddenly come up with a new idea or you might extend and improve an existing solution.

All of these difficulties are inherent in the method – solving problems is undeniably open ended and creative, but top-down focuses the mind and very rarely is a complete waste of time.