Programmers: Why should we start with a plan...?

Most of the software development tools we have today include visual designers (that contain dozens of visual screen components) that allow us to prototype our user interfaces. By prototyping we can see what our user's see and greatly improve the quality of our interface and also reduce the time needed to built graphical interfaces. This is a GOOD thing but like everything it can be abused. Prototyping the user interface is no substitute for planning the logic that sits behind the screen. This blog topic addresses this issue.

If you are going to be a programmer you have got to plan...

Why do we construct logic models (flow charts and pseudo code) to create computer programs? This is certainly a very valid question and one I have heard many times from programming students. I’ve had many new student programmers who have been in a rush to program. This is a very natural reaction. Our enthusiasm to get started along with the uncertainty of learning a new subject, drive our desire to create our first program. It is difficult to stay patient as we move through the topics of flow charting and pseudo code knowing that you can open that editor and start building your screens or writing your code.

Resist the temptation for a little while longer as we again discuss the discipline of programming. The adage “anything worth having is worth waiting for” is very appropriate explanation of where we are at in your programming training. A little patience now is important as we build a foundation that will help you become a more effective and efficient programmer.

I covered in other blogs about the discipline of programming. I explained that having discipline as a programmer meant approaching programming with a professional standardized process. This discipline has been used by other programmers and has evolved over time from numerous successful programming projects. This is not unlike the professional standards and processes developed by accountants, lawyers, engineers and other professionals.

There are many analogies I could use to demonstrate how program discipline is exhibited and why it is important. One of my favorites is building a house from scratch. We all know what a house looks like and we could go down to the local hardware store and buy the supplies and start putting together a house. Without following the standards used by professional builders (blueprints, accepted construction techniques, building code regulations), we might end up with something that looks like a house (a structure with a roof and four walls) but it’s unlikely that it would be of the quality that was found in a house built by a professional. It might have an unsafe design. We might not be able to remodel or repair the house later on because of its non-standard construction. It would a structure that would probably not stand the test of time like a house built using established standards and techniques.

How about another analogy? Are you the kind of person who doesn’t like to read directions? Do you buy a product from the store and instead of reading over the assembly instructions you simply start putting things together based on the picture on the box? When it comes to installing new software from a CD-ROM to your personal computer, do you just place the CD-ROM in the drive and take all the defaults or do you read the instructions on how to install it properly. Most of the time, the software installs okay. Sometimes the original install seems successful and after awhile you realized the software was not installed correctly and you have to reinstall again. Normally the reinstall is not a problem but you had customized your software settings, the new install will probably wipe them out so that you will need to reconfigure them again. This will be the penalty for your haste. This is why the discipline of programming is so important to becoming an effective programmer.

If you do not take the time to use good programming processes during your project (like building logic models first) and you might find a serious problem later on after the program has been in use. This is the worst kind and most embarrassing type of programming design error. Programs that require a lot of rework and repair just after installation are poorly designed programs and a sure sign that programming discipline was not followed.

What do you think? Ready to build at flowcharts?