Excel 2019 Power Programming with VBA. Michael Alexander

According to this definition, most of the spreadsheet files that you've developed probably don't qualify as spreadsheet applications. You may have dozens or hundreds of spreadsheet files on your hard drive, but it's a safe bet that most of them aren't designed for others to use.

      A good spreadsheet application does the following:

       Enables the end user to perform a task that he or she probably would not be able to do otherwise.

       Provides the appropriate solution to the problem. (A spreadsheet environment isn't always the optimal approach.)

       Accomplishes what it is supposed to do. This prerequisite may be obvious, but it's not at all uncommon for applications to fail this test.

       Produces accurate results and is free of bugs.

       Uses appropriate and efficient methods and algorithms to accomplish its job.

       Traps errors before the user is forced to deal with them.

       Does not allow the user to delete or modify important components accidentally (or intentionally).

       Has a clear and consistent user interface so that the user always knows how to proceed.

       Has well-documented formulas, macros, and user interface elements that allow for subsequent changes, if necessary.

       Is designed so that it can be modified in simple ways without making major changes. A basic fact is that a user's needs change over time.

       Has an easily accessible help system that provides useful information on at least the major procedures.

       Is designed to be portable and to run on any system that has the proper software (in this case, a copy of a supported version of Excel).

      It should come as no surprise that it is possible to create spreadsheet applications for many different usage levels, ranging from a simple fill-in-the-blank template to an extremely complex application that uses a custom interface and may not even look like a spreadsheet.

Steps for Application Development

      There is no simple, surefire recipe for developing an effective spreadsheet application. Everyone has his or her own style for creating such applications. In addition, every project is different and therefore requires its own approach. Finally, the demands and technical expertise of the people with whom (or for whom) you work also play a role in how the development process proceeds.

      Spreadsheet developers typically perform the following activities:

       Determine the needs of the user(s)

       Plan an application that meets these needs

       Determine the most appropriate user interface

       Create the spreadsheet, formulas, macros, and user interface

       Test and debug the application

       Attempt to make the application bulletproof

       Make the application aesthetically appealing and intuitive

       Document the development effort

       Develop user documentation and Help systems

       Distribute the application to the user

       Update the application when necessary

      Not all of these steps are required for each application, and the order in which these activities are performed varies from project to project. We describe each of these activities in the pages that follow. For most of these items, we cover the technical details in subsequent chapters.

Determining User Needs

      When you undertake a new Excel project, one of your first steps is to identify exactly what the end users require. Failure to assess the end users' needs thoroughly early on often results in additional work later when you have to adjust the application so that it does what it was supposed to do in the first place.

      In some cases, you'll be intimately familiar with the end users—you may even be an end user yourself. In other cases (for example, if you're a consultant developing a project for a new client), you may know little or nothing about the users or their situations.

      How do you determine the needs of the user? If you've been asked to develop a spreadsheet application, it's a good idea to meet with the end users and ask specific questions. Better yet, get everything in writing, create flow diagrams, pay attention to minor details, and do anything else to ensure that the product you deliver is the product that is needed.

      Here are some guidelines that may help make this phase easier:

       Don't assume that you know what the user needs. Second-guessing at this stage almost always causes problems later.

       If possible, talk directly to the end users of the application, not just their supervisor or manager.

       Learn what, if anything, is currently being done to meet the users' needs. You might be able to save some work by simply adapting an existing application. At the very least, looking at current solutions will familiarize you with the operation.

       Identify the resources available at the users' site. For example, try to determine whether you must work around any hardware or software limitations.

       If possible, determine the specific hardware systems that will be used. If your application will be used on slow systems, you need to take that into account.

       Identify which versions of Excel are in use. Keep in mind that users can have versions of Excel running on macOS, mobile platforms, and Windows. These have to be taken into account when planning an automated Excel solution. Although Microsoft does everything in its power to urge users to upgrade to the latest version of the software, the majority of Excel users don't.

       Understand the skill levels of the end users. This information will help you design the application appropriately.

       Determine how long the application will be used and whether any changes are anticipated during the lifetime of the project. Knowing this information may influence the amount of effort that you put into the project and help you plan for changes.

Finally, don't be surprised if the project specifications change before you complete the application. This occurrence is common, and you're in a better position if you expect changes rather than being surprised by them. Just make sure that your contract (if you have one) addresses the issue of changing specifications.

Planning an Application That Meets User Needs

      After you determine the end users' needs, it's tempting to jump right in and start fiddling around in Excel. Take it from those who suffer from this problem: try to restrain yourself. Builders don't construct a house without a set of blueprints, and you shouldn't build a spreadsheet application without some type of plan. The formality of your plan depends on the scope of the project and your general style of working, but you should spend at least some time thinking about what you're going to do and coming up with a plan of action.

      Before rolling up your sleeves and settling down at your keyboard, you'll benefit by taking some time to consider the various ways that you can approach the problem. This planning period is where a thorough knowledge of Excel pays off. Avoiding blind alleys rather than stumbling into them is always a good idea.

      If you ask a dozen Excel experts to design an application based on precise specifications, chances are that you'll get a dozen different implementations of the project that meet those specifications. Of those solutions, some will be better than the others because Excel often provides several options to accomplish a task. If you know Excel inside and out, you'll have a