Learning to Program—The stages of programming


This entry is part 1 of 22 in the series Learning to Program

In order to become an effective programmer, you need to understand a few things about programs.  You should understand what a program is, and what it does.  And you should understand the stages of programming.  Also, the stages of programming will serve as a guide for how I plan on writing this series.

First and foremost.  What is a program anyhow?  The technical definition of a program is a series of instructions that a computer uses to perform a specific action or actions.  But, for the purposes of introducing you to logic, think of a program as a recipe for creating something.  And think of a program as a manner of solving a problem.

Now, what is a problem?  A problem could be something wrong, or it could be like a math problem.  In reference to programs, it’s a little of both.  The problem is the question that you’re trying to answer, the feature or idea that you’re trying to create, or the fix for something that’s wrong with an application or system.  The program that you create will be the solution to that problem.

And remember also, that no program will ever be 100% perfect.  If it was, then there wouldn’t be a need for programmers.  Plus when you get into the millions and billions of lines of code (and have multiple people writing this code), it’s impossible to catch every single bug.  Typical example that I’ve heard is “If it’s about 95% bug-free, and the bugs are minor or impossible to find, then it’s considered release quality.”

The stages of programming:

This is assuming that you already have the problem in hand.  Meaning that you have the request for a program, or you have the idea for the program in front of you.  If not, then that would be the first true stage (defining the problem).

Stage 1:  Creating an IPO chart for the problem.  An IPO chart defines what data will be inputted into the program, what processing will take place on that data, and what will be the output of the program.  It will help to further clarify the problem and solution.  And it will help to decide what variables need to be used.

Stage 2:  Design a flowchart for the program. This is an optional stage in some cases. However, most colleges still teach it, because it gives you a graphical (visual) idea of what the program does.  A flowchart should be code independent.  This means that you can take a flowchart and code it into any language.

Stage 3:  Write pseudocode for the program.  This stage is usually done in conjunction with stage 2.  Pseudocode is half-baked code.  You will take the symbols from the flowchart and the actual flow of the chart, and use words to describe them.  It can be code independent or code-dependent.  You should be able to start with a flowchart and make pseudocode or vice versa.

Stage 4:  Coding the program.  This is the stage where all of the magic happens.  You take your flowchart (or pseudocode if you created it) and write actual code in the language.  Then you compile the code to make sure that there are no syntax errors (or compiler errors).  Try writing code from a flowchart and then try writing code from pseudocode, and you will immediately see the value in having stage 3.

Stage 5:  Testing the program and fixing bugs.  This stage runs concurrently with stage 4. As you code and compile your program, you’ll want to run it to make sure that everything behaves as it should.  You should create a test application, which makes use of the different classes and methods in the program.  Then you should use that to test everything out.  Finally, you’ll create the main application which does whatever the program is supposed to do.  (More about this as we get deeper into Stage 5)

Stage 6:  Documentation.  You should be doing this the entire time, but this is the stage where you put everything together.  Your documentation should include the IPO charts, the flowcharts, the pseudocode, the actual source code, and any comments or other files that explain the problem and solution.  This documentation needs to be maintained along with the code, and should be done in such a way that you (or I) can walk in three years from now, and understand what was done.

Stage 7:  Maintenance.  This is the stage that you will spend at least 50% to 75% of your time in.  Either you will be maintaining your own code, or someone else’s.  Just because the program is done and released, doesn’t mean that you’re finished with it.  Bugs that are found later on will need to be fixed.  Features will need to be added or removed.  Upgrades will be created.  The list goes on and on.

Next I will start to describe Stage 1 and go over some of the things you need to understand (like variables and constants).  As we hit other topics, I will explain them also.

Have a great day:)
Patrick.

Series NavigationLearning to Program – Some Terms You Should Understand >>

Leave a comment

Your email address will not be published. Required fields are marked *