Problem Solving

DIGG IT!     Published Tuesday, June 16, 2009 at 10:48 AM .

One of the key parts of software development is problem solving. Like most problems in the real world software, problems can be broken down into many nested smaller problems and thus become much easier to solve. Breaking problems apart requires a deep understanding of the problem at hand and in many cases this is actually 80% of the problem itself. Once you understand the problem, writing a solution is pretty easy.



In my experience, to fully understand a problem you need to wrestle with it a bit. This requires some level of a throw away solution as you learn how something works. I tend to plan for throw away versions when major problems are identified within a software project. Generally it pads the development schedule and gives ample time for understanding and solving problems. Many lump these together as one thing but in reality understanding a problem and solving it are very different things. The only thing you need to watch out for is when "understanding the problem" code make it into a main build when this should really be rewritten.



Have you ever lost code? Why is it that you can recode a solution so quickly the second time? The second time you understand the problem at hand and solutions are easy to write when you understand them. Better still the 2nd solution tends to be more thought through and is most often cleaner with optimization built in (vs created early, read evil).

Breaking problems into smaller parts can be very hard to do. Getting from A to G requires you to solve BCDEF but what are BCDEF in terms of problems? I tend to make a procedural list once I have identified the larger TODO. A-G is a TODO item but solving BCDEF isn't. I typically make a check list of the things that need to happen to solve the TODO level problem. It helps me see the smaller elements in context with the larger problem. In many cases these smaller parts are helper methods and small data management tasks or UI related tasks. Here is a simple case:

TODO:
Load DataGrid with Data

Checklist:
1. Create http networking
2. Make call to server
3. Create server result in XML
4. Return result to client networking
5. Parse result data set
6. Clear out data in DataGrid Component
7. Create Typed Objects from XML data results and Add to Model
8. Set Model to DataGrid

The todo is simple but the checklist within really reads like code. I typically make the checklists for any solution inline as comments and write code around them. It provides some structure as I write code and the nature of the problem is within the documentation/code before I write any logic. This also allows you to build test cases and really helps close the quality gap. You need to know for sure that a problem is solved and testing is the only real way to know for sure.

So in a nutshell, break problems into smaller problems and plan to write some "understanding the problem" code before you write a solution. These simple steps have really helped me write logic faster with fewer errors over the years and I am sure it well help you solve the many problems you run into.

Cheers,

Ted :)

---