If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Since starting the PHP programming contest I have been thinking a lot about problem solving. And specifically problem solving within programming. Early on in most people’s programming careers problem solving is a large part of your day to day job. As you become more experienced you find that many programming patterns that you have used before can be reapplied. You then start working on larger and larger projects and the problems tend to be more about solving architectural problems rather than logic related ones.

Talking it through
A lot of problems can be easily solved by just talking. If you work within a team of programmers just explaining the problem to another programmer can mean by the time you have finished explaining it you have already solved it (I am sure you have all had this happen). Why is this? Most problem solving is all about breaking the problem down, by explaining it you are automatically breaking it into parts, this then naturally leads to an easier solution which becomes obvious while you explain it.

Brainstorming
If after explaining the problem you have not come up with a solution (or a solution you are happy with) then a possible next step is brainstorming. This can often be associated with a group of people sitting around in a meeting room all getting excited scribbling rubbish on a whiteboard. To me any programming solving discussion is a form of brainstorming. Although I am not a fan (can you tell) of the typical brainstorming routine it does have a number of concepts which are important.

1. Combine and improve ideas: When coming up with numbers of ideas it is important to keep track of all of them (damn that whiteboard). As each idea may not be a solution in itself but you can continue to combine and improve during the session. Most complex problems can be solved by the use of building blocks and each idea must be viewed as a potential building block.
2. No criticism: Leave the idea bashing to when you have run out of new ideas. Be constructive about all possible solutions (evening if you can see fatal flaws) because you never know how one idea may interact with another, if you cut a possible solution down immediately it may be discounted and never have a chance to work with other possible ideas. This leads onto.
3. Quantity: Keep them coming. There is a saying ‘quantity breeds quality’ not sure I completely agree with that but ‘time = ideas’ so do give yourself time to produce as many ideas as you can.
4. Unusual ideas: To get quantity you need to think ‘out there’. Unusual ideas are welcome and may open up new ways of thinking in other members of the group. They can often be generated by looking from a different perspective or setting aside assumptions.

Lateral thinking
How do you teach someone to think laterally? I have no idea but I know it is something I do but it is not something I consciously decide to do when solving a problem. If I have worked hard on a particular problem for a whole day without any results I can pretty much bet that at 9am the next morning when I walk into work my brain will have come up with something. This can sometimes be something obvious but a lot of the time it will be a form of lateral thinking. So my answer? Sleep on it.

Breaking it down
In many situations the need to breakdown a problem into its component parts is required to make the problem manageable. The fact is that some problems are just too big to fit into your head and breaking it down allows you to think about each part while still solving the overall problem.

The breaking down process can be helped by using a range of techniques and you must choose the right one based upon the problem itself. At a larger scale I often use paper to map out my ideas into blocks. I then use some form of electronic note taking software to split each of those blocks into a smaller programming problem. This may mean a list of potential object classes or even a list of methods which I think I will need.

Pseudo code
I have previously done an article on Pseudo code and I recommend you to read it.

Trial and Error
For many simple problems in which no obvious answer is apparent the use of trial and error can help move the problem forwards. I cannot remember a time when I have started solving a problem using trial and error but I have on many occasions thought of a solution then implemented it only to find that it was not exactly what I wanted. In these circumstances you generally then have two choices.

1. Start again
2. Continue via trial and error

Research
99.9% of the time someone else will have already solved the problem you are trying to solve. The problem can sometimes be finding that solution. The internet is a wonderful research tool (especially Google) but I always take the following points into account.

1. How long will it take to find the solution vs solving it yourself?
2. Once the solution is found can you understand it? Some research material I find can use some pretty esoteric notation which I have long forgotten how to read.
3. When researching some particularly unusual problems I have often found that a lot of the sources are within books. This can be a problem in itself as the cost must then be weighed up against your time.
4. Finding solutions with sample code can be a cure and a curse. If you are especially lucky enough to find code in the programming language you are using I recommend just using it reference. Given time you will always find that your own solution will fit better.
5. Is the solution you found patented?

That is a brief summary of the generalized techniques I recommend (that does not take into account any particular programming methodology e.g. Agile, Extreme, Collaborative) but I would be very interested in hearing about your ideas and stories on how you may have solved a particularly difficult problem.

And lastly if you have not already check out the PHP Programming Contest.