5 Key Parts to Problem Solving in the Software Development World.
How do you get from a set of requirements to a working program? There is no cut-and-dried recipe to follow.
If there were, someone would write a program to do it, and computer programmers would be obsolete.
However, there are general principles you can follow that will help to guide you toward a solution. (Based on How to Solve it by George Pólya.)
#1 Make sure you have a clear understanding of all the requirements.
In the real world, this is sometimes the most challenging part. Without this, the product you create (i.e the code your write, the design you create, etc.) will be completely off from what an instructor or client is expecting.
However, this is probably the number one thing people know they need to do when getting some kind of assignment or job. How can you ever be expected to code hundreds, possibly thousands of lines without fully understanding what you are doing.
#2 Plan Tests you can use to check potential solutions for correctness.
If you don’t have a way to test an assignment or job and make sure it fits the necessary requirements set by your instructor/boss then you will move forward ignorant to the potential issues.
This obviously can cost you letter grades or more importantly money & time!
#3 Design the approach.
One of the most commonly used methods for this is stepwise refinement (AKA the top-down design). This is a process of breaking up the original problem into some number of smaller sub-problems.
Next, you take each sub-problem and break it up into even smaller sub-problems. This is repeated until you get sub-problems that are small enough to be translated into code.
This approach can be extremely helpful to not only beginners trying out something new or difficult. It also can help people who have been doing this for years. The process of getting the idea, transitioning it to paper, and then working through the problem, allows you to understand the issue quicker and easier.
#4 Translate your design into computer code (checking it with the tests from #2).
OK, this is probably the most anticipated part of the whole process. Seems simple right? It should be after your extremely thoughtful planning and design work. You can see that the process doesn’t work if you go from step one to step four.
Another side note here, is the amount of time you plan and design. Like dieting and losing weight, the workout or the cardio is only a small part, the diet is the biggest percentage. This is the same as coding. The planning and design is the majority of the work while the actual coding is only a small part.
#5 Reflect on how you arrived at your solution.
Last but certainly not least, the reflection. I usually write notes of issues I had while writing the actual code or if I found something better that I didn’t know about. If you keep a notebook nearby to jot down notes you can go back to them when you are implementing something.
The reflection also allows you time to go back through, add testing measurements if need be and ask things like, what worked and what didn’t? How can this experience help you solve future problems? Which of course leads to you being a better developer in the long run.
Check out my blog to get these posts first! And be sure to follow me on twitter!