Chapter 1. Professional Programming as Style
Walk into any dentist's office and you will probably find copies of Highlights for Children on various tables and magazine racks. As a child I would nervously bide my time behind the covers of this journal. As you may recall, every issue of Highlights has a cartoon series named "Goofus and Gallant." The panels of the strip present contrasting views of the lives of two young boys, Goofus, an incorrigible troublemaker, and Gallant, every mother's favorite child.
Goofus and Gallant are still the same ages they were decades ago, but what if they did grow up? Imagine that they are both in their early thirties and they both hap pen to be programmers (see Figures 1-1 and 1-2)
Figure 1-1. Goofus starts writing code without putting much thought into the user's needs or his company's concerns.
Figure 1-2. Gallant works with the user and his coworkers to design and implement the best software solution.
Goofus and Gallant truly represent the opposite ends of the selfishness continuum; most people fall somewhere in between these two extremes. Still, these two characters portray two paths that can be followed in many areas of life: the path of reckless selfishness and the path of thoughtful professionalism.
Although you purchased a book on programming style, you are really holding a book on professionalism. Without maintaining a professional demeanor in your programming endeavors, you will not create quality systems. Of course anyone can make something look good, but thoughtfulness and a concern for quality are requirements to make something, such as an application, good on its own. This volume begins the discussion of style with its most important focus: professionalism in programming.
What is professional programming? Is it holding down a job at a software company? Is it having "software engineer" or "programmer/analyst" printed on your business card? While professional programmers often have these things, they alone do not indicate who is truly professional. Professionalism is something that grows and lives inside the heart of the programmer. Good style flows from this wellspring of quality, affecting not only the programmer's applications, but his or her entire work ethic.
Programming in Visual Basic is fun because it is so simple to create a full-fledged Windows application. When the Visual Basic development environment first starts up, you are presented with a blank form that represents a fully functional Windows program (just press F5 to prove it). The programmer's job is to mold that core program into a useful and useable application. However, not all Visual Basic programs are created equal. Some applications exhibit the characteristics of a professional program. These characteristics include, but are not limited to, a consistent user interface, clearly defined usage, user documentation, and freedom from bugs. Other applications lack some or all of these features. There are many reasons why poor Visual Basic programs are written.
Lack of planning. Active development of the application begins without careful consideration of the flow of the program, or the needs of the user.
Lack of skill or talent. One or more of the programmers or managers involved in the Visual Basic project are not adequately prepared to meet the challenge of professional Visual Basic application development.
Lack of training. Although those involved in the project are competent enough to complete the project, proper tools, training, and documentation are either unavailable or overlooked.
Lack of management. A disproportionate share of the burden of project management is placed on the shoulders of the programmer(s) instead of on management.
Lack of time. A predetermined implementation schedule fails to take into account the complexities of application development and deployment.
Lack of discipline. A clear set of rules, guidelines, and constraints, whether formal or informal, are placed neither on the management of the Visual Basic project, nor on the activities of the programmers.
Lack of scope. New components of the project are added on a continual basis without proper analysis of needs or time requirements.
Any one of these symptoms can lead to the eventual downfall of a Visual Basic application. When several (or all) of these deficiencies are combined, failure is almost certain. However, these problems can all be prevented, and the chances of success substantially improve by applying the effective methods described in this book.