Home > Articles

What Makes a Professional Application?

New Term

If you read one or more Visual Basic books or have worked with Visual Basic for any length of time, you've probably created many small programs, trying out Visual Basic's different features. After you do this for a while, you've probably asked yourself, "What do I do now?" By using all the tools, controls, and objects that you've learned, you can really impress your friends and family with the things you can get the computer to do. To do anything useful on your computer, however, you need to create larger and more complex programs, or groups of programs called applications. Whether the application you're creating is a small inventory program for the house, a personal phone book, or possibly a personnel tracking system for your office, many things go into creating it. If you take a close look at most popular pieces of software on the market, such as Microsoft Money, you can see that many different related routines create the single application.

Whether you're a seasoned programmer or a newcomer to the industry, everyone dreams of creating an application they can sell. Next time you go into a computer store, look at the numerous software applications available; most of them started as one person's idea. If this is where you're heading, you need to know how to plan your application accordingly.

When developing an application, most programmers don't consider what happens when they're done creating the application. If you're working for a company, the finished application is handled differently than if you're planning to sell the application yourself. Putting everything together into one package takes patience, time, imagination, a little luck, and lots of planning. If all goes well, the finished product will look good and work well.

Application Types

You might not realize it, but you can create three distinct types of applications. If you're just starting out as a developer, this might seem a little strange. An application is an application, right? Wrong! Depending on where you work, the type of application you're creating, and the application's final audience, the package you create will be quite different.

You might create three types of applications:

  • A personal application is one that you create for yourself and no one else. You probably won't create any help files or a manual for your own application. Also, because it's running on your own PC, you won't create any distribution disks. As you can see, a personal application is like keeping a private journal; no one else will ever know about it unless you tell them.

  • When working for a company, most applications that you develop will probably be internal ones used by other employees of that company or by company clients (for example, home banking software). If the application is completely internal, you don't need to consider any issues that deal with marketing the application. However, you do need to create a help system and a manual because you aren't the only one that will be using the application. Users must have some type of documentation to refer to when using the application.

  • If the application is for company clients or for retail distribution, marketing and advertising must be included in the overall process.

In the current Web-focused environment, these types even extend out to the Internet. You can develop applications that run entirely on a Web browser (like many banking applications), or run locally on the PC from the Web without installing the application before using it. Of course, there is the old standard of installing the application directly on the PC.

Picking the Right Application

New Term

Before jumping in and creating an application, you need to decide what function the application will serve. This decision isn't as easy as it might sound. For every idea that you can think up, probably 10 other people have had the same idea. Depending on whether you're creating an application to learn more about programming, something that you want to use at home, or an application to sell, you need to do some market research about what the application will do. If you're selling, it's very important to understand the type of person who would use it and how many you might sell. This helps you decide whether it makes any sense to go any further with the idea.

Without doing market research, you might create a great product that nobody wants or a product with so many competitors that it gets lost in the crowd. If you find that too many other products of the same type are already on the market, you might decide to select a different type of application or to place the finished product into the realm of shareware (discussed later in this book). For instance, you don't want to spend the time creating a word processing product with products such as Word and WordPerfect already on the market.

In short, you need to select an idea that's new—or at least different—and run with it. You also have to compare the cost of creating and advertising the product versus your available cash and expected sales. After you decide on the application, however, jump in and start the process. You definitely want to get your product to the public as quickly as you can, with the best quality possible.

Project Life Cycle

New Term

When creating an application, you must take several steps to ensure that it's done correctly. These steps are generally grouped together and called the project life cycle. Although the number of steps in this cycle can vary depending on the project's complexity, every project must take several universal steps. These steps, or standard life cycle (see Figure 1.4), allow you to plan each section of work and set goals to help verify that you're ready to move on to the next step.

Figure 1.4 The standard project life cycle used in the creation of most computer applications.

Many newer Windows programmers tend to sidestep this approach and prefer to start coding their application immediately. Doing so, however, usually causes problems later on. If you don't plan or blueprint your application, you could wind up forgetting something important, thus having to redo large portions of your work just when you thought you were finished.


The most difficult part of creating any application is deciding what it will do. When that's accomplished, the rest becomes relatively easy. The time you spend designing an application is the most important portion of the project. As mentioned earlier, some programmers like to jump right in and start coding. For every hour that you spend designing your application, you could wind up saving as much as a day of debugging time. If you start with a good design, you'll have considered many more of the situations that might cause problems later and resolve them before they occur.


Fixing design problems on paper is always easier than after they're coded.

In reality, the design step in the life cycle is a cycle itself (see Figure 1.5). Designing an application consists of creating the application's design description, functional definitions, technical definitions, pseudocode, and finally form layouts. From all these steps your actual Visual Basic code will flow. You should expect the design phase of the life cycle to take the largest percentage of time.

Figure 1.5 The design phase of the life cycle is a cycle of steps itself.

After you write down the functional definitions for your application, you start translating them into a technical definition. As you move from one step to the next, you'll probably find things that you missed the first time; back up, rewrite that definition, and then continue forward again. In this way, when you start coding, it will be almost a line-for-line translation from your pseudocode to Visual Basic code.

If you think of designing an application the way a house is designed, you will get a good feel for the step-by-step approach you should set up before actually building the application. For example, you wouldn't put the roof of the house up before the walls are put into place, and you wouldn't put the walls up before the foundation is poured. You also wouldn't take a pile of lumber and just start nailing the wood together without a plan. If you did this, your house wouldn't be habitable. It's the same with an application. The plan, or design, is the foundation of the application. If you start with a good foundation, your application will hold up, no matter how hard it's used.

To get a good design, you need to understand what the application will consist of. A house and an application must be built according to a carefully laid out series of steps. In a Visual Basic application, you don't want to create any code before you create the forms, or create the forms or their functions before you know what types of forms you need.

If you build the application in the wrong order or leave a part out, it will be that much harder to add the code when the rest of the application is finished. It could take longer to finish, or never work at all. To design an application correctly, you must first understand what you want it to do.

The first step in the design process is to put the overall application definition into words. This is usually done by writing a short paragraph describing exactly what the application is and what it will be able to do—for example,

Personal Address/Phone Book. This application will keep track of names, addresses, and phone numbers by name. It will allow as many different addresses and phone numbers as needed. It will also allow the entry of some personal information (such as birth date, spouse's name, and children's names) to be determined later. It will provide reports in several formats and allow users to search the database for a particular person.

This example presents you with a good idea of what main functions the application will perform, giving you a final goal to aim for as you define the more detailed functions in the application. As an alternative to describing the application in a paragraph, you could list the main functions of the application in an outline format as follows:

Personal Address/Phone Book

Name/address/phone number entry and display

Personal Information entry

Searching for selected names, state, type, and so on


Data backup and recovery

Multiple database files

This method would also give you a road map to follow when defining the functions in more technical detail. A good method for putting the functional definitions on paper is to describe each function in detail. When doing so, you should try to describe in sequence all the events, options, and results that might occur when users choose this function in the application. You might also describe how this function interacts with other functions in the application. Keeping to a conversational style when describing each function makes it easy to understand what each function will be doing. A definition of a data entry form in this type of style is as follows:

Data Entry. The data-entry form will allow entry of the following information: name, address(es), phone number(s), spouse, child names and ages, and other miscellaneous information about the person being added.

This function must allow for as many different addresses, phone numbers, family members, and miscellaneous information as needed. The number can vary from entry to entry. It will also check if the input is correct (that is, validate that the phone number has the appropriate number of digits). Also, it will verify that the person being added isn't already in the database. Finally, a modification and delete function will be supported.

New Term

As you can see in this example, the main function is broken into subfunctions, which describe each step within the main function, such as what the application will do when the entry form's Update button is clicked.

New Term

The next step in the design process is taking these functional definitions and translating them into a technical definition or pseudocode. Pseudocode is a style and a technique that allows you to define a function in such great detail that you can almost write the Visual Basic code from the pseudocode. The problem with the technique is that it's not as easy as it sounds because most of us don't think like a computer. When you force yourself to create the pseudocode, however, you'll find that many technical issues that you didn't think of are discovered and added to the design or removed from the application. The following simple function demonstrates how pseudocode would look:

Duplicate Name Check
Input: Name of person being added to database.
Get input name
Initialize SQL statement to query the database for the input name
Execute the SQL statement
Check the query resultset
If no records are found – return a 0 to signal that no duplicate records
  were found
If a record was found – return a 1 to signal that the entry is a duplicate
Close the query
Exit function
Error Process:
If an error occurs
Display the error number and message to the user
Return the error number to indicate a problem occurred while checking
  the database

As you can see, because this is almost Visual Basic code by itself, translating it into actual Visual Basic code will be far easier than if you didn't do this type of designing.

Finally, you need to define the forms and reports you'll need according to the functions already defined. This is more difficult to do because there's really no set way of doing this type of design. You'll find many tips, concepts, and suggestions about form design (as covered later in this book); however, it really comes down to personal choice on how the forms will look.

With all that said, remember that the design you finally come up with isn't set in concrete. You can and should go back over the design several times, looking for possible problems before you start creating the actual application. This critical review of your plans is an important part of the design process.


Well, you've done it. You made it past the design phase of your project. Be proud that you did; more than half of all application projects never make it this far. Now you're ready to start coding, but don't bite off more than you can work on at one time. Also, treat the coding process like you're peeling an orange. Start by coding the main form of your application with the menu and button bar in place (see Figure 1.6). When you code your application, start with what the user will see when it's started.

Figure 1.6 Main form of a sample application showing the skeleton of the user interface.

At this point, if you selected any menu or button options, nothing much would happen because you haven't written any code related to those options. Writing code for the computer isn't as simple as writing a letter. The code placed in a Visual Basic application is organized hierarchically. An application generally consists of one or more modules, including form modules, one for each form in the application; standard modules for shared code; and possibly class modules. Determining which procedures belong in which module depends somewhat on the type of application you're creating.

There are certain ways or conventions for formatting and labeling everything in program code. Coding conventions is an attempt to standardize the structure and coding style of any application so that you and more importantly others can easily read, understand, and maintain the code. Because most applications aren't as simple as the "Hello World" example most books use to teach programming, the organization or structure of your application code becomes very important. Depending on what a section of code does and where it's used, you would place it in different areas of your application. Code is placed in three areas:

  • Event procedures are subprograms coded to execute in response to specific events in your application.

  • Standard code modules are subprograms not related to a specific form or control that might be used by objects in different forms.

  • Class modules contain code and data.

By structuring your code properly and following good coding conventions, your source code would be more precise, readable, unambiguous, and as intuitive as possible.


The object of conventions is to make the application code easy to read and understand without inhibiting your natural creativity with excessive constraints and arbitrary restrictions. For this reason, the conventions suggested here are short and entirely voluntary. This section isn't attempting to tell you how your coding should look or be done; it's only making some suggestions.

Listing 1.1 is a before example of a coded function.

Listing 1.1 Hard-to-Read Code

Private Sub save_but_Click()
Me.Cursor = System.Windows.Forms.Cursors.WaitCursor
noupd_ent = False
If new_but.Enabled = False Then
Set logset = logdb.CreateDynaset("cdt_tbl")
logset.FindFirst "[first name] = '" & fname.Text & "' and [last name] =_
   '" & lname.Text & "'"
If Not logset.NoMatch Then
noupd_ent = True
Me.Cursor = System.Windows.Forms.Cursors.Default
MsgBox("Duplicate Candidate Name Entered")
Exit Sub
End If
End If
If data1.Recordset.EOF And data1.Recordset.BOF Then
norecs = True
bk = data1.Recordset.BookMark
norecs = False
End If
If Len(lname.Text) = 0 Then
Me.Cursor = System.Windows.Forms.Cursors.Default
MsgBox("You Must Enter a First and Last Name.", 32, setmsg)
Exit Sub
End If
loading = True
cdt_sel = data1.Recordset.Fields("cdt_id").Value
noupd_ent = False
Me.Cursor = System.Windows.Forms.Cursors.Default
End Sub

When you enter code, the two easiest things that you can do are add comments to the code and consistently indent the code so that different logic blocks become obvious (for example, If...Then...Else...End If). Both conventions improve the overall readability of your code. To further the trend of commenting your application, you should have a brief comment box at the beginning of each procedure and function to describe what the item does (but not how). Any arguments passed to the procedure should be described when their usage isn't obvious or when a certain range of values is expected.

You've probably also read about the need for naming conventions. In a Visual Basic application, every object, constant, and variable needs to have a well-thought-out name. Each name should include a prefix that defines the data type it's defined as. For example, strFirstname tells any programmer that the variable is defined as a string and that it's used to hold the first name for a data entry.

To show you how all this helps, the earlier sample code has been rewritten with all these conventions (see Listing 1.2).

Listing 1.2 Properly Formatted Code for Easy Reading

Private Sub cmdSaveRecord_Click()
'* This routine will check to see if the person being added to
'* the database is already there. If it is not on the database then
'* it will complete the ADDNEW function by issuing an UPDATE against
'* the database.
'* The variable vntBookMrk is used to pass the pointer to the current
'* record. The variable intNoRecords is used to inform the calling routine
'* if the Record was found or not.
 Me.Cursor = System.Windows.Forms.Cursors.WaitCursor
'* If this is a new entry check to see if it already exists
 If cmdNewEntry.Enabled = False Then
  Set recLogRecord = dbLogBook.CreateDynaset("cdt_tbl")
  recLogRecord.FindFirst "[first name] = '" & txtFirstName & _
        "' and [last name] = '" & txtLastName & "'"
  If Not recLogRecord.NoMatch Then
   Me.Cursor = System.Windows.Forms.Cursors.Default
   MsgBox("Duplicate Candidate Name Entered", _
     VBExclamation, Form1.ActiveForm.Text)
   Exit Sub
  End If
 End If
'* If no records were found set intNoRecords to True
 If datLogEntry.Recordset.EOF And datLogEntry.Recordset.BOF Then
  intNoRecords = True
  vntBookMrk = datLogEntry.Recordset.BookMark
  intNoRecords = False
 End If
'* If the last name was not entered then display an error message
'* to the user and exit the routine
 If Len(txtLastName) = 0 Then
  Me.Cursor = System.Windows.Forms.Cursors.Default
  MsgBox("You Must Enter a First and Last Name.", _
     VBExclamation, Form1.ActiveForm.Text)
  Exit Sub
 End If
'* if you got this far update the record.
 intEntryKey = datLogEntry.Recordset.Fields("cdt_id").Value
 Me.Cursor = System.Windows.Forms.Cursors.Default
End Sub

As you can see from this final version of the routine, the code becomes very easy to follow. Related If...End If statements are easy to spot, and the comment box explains the routine's overall purpose.

New Term

In the routine, notice that two variables are Public—meaning that they were defined outside the routine. The scope of your objects, constants, and variables are important. They should always be defined with the smallest scope possible. Global variables can make the logic of an application extremely difficult to follow. They also make it much more difficult to reuse functions or subprograms in other applications. The concept of scoping is covered later in this book.

Testing and Debugging\

New Term

After you start coding your application, you need to start the process of testing the code to see whether it works and to fix or debug the code that doesn't. Not everyone tests as thoroughly as they should; this is attested to all the fixes and upgrades to existing software. Then again, no matter how much you test, there will always be bugs that you didn't find. In addition to bugs that you didn't find in the first place are bugs introduced into an application whenever changes or other fixes are applied to the code. To prevent much of these types of bugs, you should do what's called regression testing—retesting everything that has been tested before.

You'll actually be doing two levels of testing:

  • Unit testing. Testing individual routines or sections of code. An example of this would be to test just the code for the data-entry routine and nothing else.

  • Integration testing. Testing all the different units as a single system.

When testing your application, try not to use data or input that you know will work. The real art in testing is to pick test data that most likely will cause errors. You also can try the "what-if" method: Ask yourself what would happen if the user does something unexpected, such as enter letters in a phone number text box. After you begin testing your code, errors will show themselves.

The other half of this team, debugging, is the process of identifying the cause of an error and correcting it. (Testing, on the other hand, is the process of detecting the error when it occurs.) On some projects, debugging occupies as much as half of the total development time and, for many programmers, is the hardest part of programming.

The testing and debugging process is a long and arduous task; however, Visual Basic comes with some great tools to help you test and debug your application code. On Day 14, "Testing and Debugging the Application," you'll see how to use all these tools. One thing that you must pay close attention to is the usability of the forms that you create for your application. Making sure that the application you've created is intuitive to use is part of the total testing process.


It doesn't matter how great your forms are; sometimes users will need help. A help system for an application should include online help and a user's manual; it might also contain other features, such as ToolTips, status bars, What's This help, and wizards.


The software industry has been moving away from the old-style printed user manuals and have replaced them with either an HTML or PDF electronic format.

Online help is important for any application—it's usually the first place users go when they're having problems or have questions. Even a simple application should provide some type of help; not providing help assumes that your users will never have any questions.

Conceptual documentation, whether printed or provided in electronic format such as a Word document, is helpful for all but the simplest applications and can provide information that might be difficult to convey in the shorter help topics. At the very least, you should provide documentation in the form of a ReadMe text file that users could print out if desired.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020