Programming Process
The Problem-Solving Process
Experienced programmers develop their own process of tackling problems. They will consolidate or even skip steps, but most of them will admit that when they first learned, they followed a more structured approach. Programming usually revolves around a problem-solving process as follows:
1 Define the problem. The first step in the process is to clearly define the problem. This step can be as simple as brainstorming; however, there is usually a need to develop requirements of some sort. In other words, “What is the problem we are trying to solve?” The next question to ask is “What are the high-level functions that will allow us to solve that problem?”
2 Distill the problem down to byte-sized chunks. At this point, the high-level functions may be hard to wrap your mind around. In fact, they may be very abstract, so the next step is to break the high-level functions into smaller ones through an iterative process until they are easy to digest.
3 Develop pseudo-code. The term pseudo means fake. Pseudo-code refers to the clear, concise description of logic or computer algorithms in plain English, without regard to syntax. In fact, there is no precise syntax for pseudo-code. That said, most programmers gravitate toward a format like their favorite programming language.
4 Group like components into modules. This is an important step. Recent programming programs rely on a concept called modularity. Simply put, modular means self-contained and reusable bits of code-after all, why reinvent the wheel if the module already exists? Over time, programmers develop their own software module library or learn to quickly find others and incorporate them into their own programs. Modules are loosely related to functions or procedures in most languages.
5 Translate to a programming language. At this point, you should have pseudocode that resembles your favorite programming language. It’s a simple process to add the nuances of your favorite language, such as its syntax and format. Then run your favorite compiler to turn the source code into machine language.
6 Debug errors. The term bug (as it relates to hardware) was first coined by Thomas Edison, but it was Navy Admiral Grace Hopper who made it famous
when she found a bug (actually a moth) while cleaning the Harvard Mark II calculator in 1945. Many credit her with coining the term debugging, which means to remove any errors in either computer hardware or software. For our purposes, there are two types of programming errors or software bugs that require debugging: syntax and runtime.
- Syntax errors Syntax errors are caught by the compiler during the compiling process, and are the easiest type of error to find and fix. The compiler usually provides enough information to allow the programmer to find the syntax error and fix it.
NOTE: Many black and gray hat hackers will modify the source code for their exploits and purposefully add syntax errors to keep script kiddies from compiling and running them. The source code could be crippled by removing needed syntax (for example, missing ; or {}).
7 Runtime errors. Runtime errors are harder to find and fix. They are not caught by the compiler and may or may not be found during program execution. Runtime errors (or bugs) are problems that will cause the program to act in a manner not intended by the programmer. There are too many types of bugs to cover in this chapter; however, we will focus on input validation errors. These errors occur when the user provides input in a manner not foreseen or handled properly by the programmer. The program may crash (at the least) or may allow the attacker to gain control of the program and the underlying operating system with administrator or root level access (in the worst case). The rest of this chapter will focus on this type of programming error.
8 Test the program. The purpose of testing is to find the runtime errors while confirming the functionality of the program. In other words, does the program perform as planned without any unforeseen consequences? It’s the latter part of this question that’s the hardest to answer. The problem centers around the fact that a programmer is often the last person to find all of the runtime errors. The programmer is typically too close to the program to think outside the box. It is usually best to separate the testing and programming functionalities and have separate people perform them.
9 Implement production. Unfortunately, for too many software products, production begins as soon as the program compiles without syntax errors and without adequate testing. There’s often a rush to market and a ready acceptance that bugs will be found and handled later.
