Some Strategic Issues

Before we take a closer look at Visual Basic 6, we need to examine several general factors: priorities, technological progress, and overall project organization. Without understanding and controlling these factors, the best developers in the world can't avoid producing defects. These issues are not really Visual Basic 6-specific. Their effect is more on the whole development process. To extend the bug/beastie analogy onto even shakier ground, these are the real gargoyles of the bug world. Their presence permeates a whole project, and if left unrecognized or untamed they can do severe and ongoing damage.

Priorities: The Four-Ball Juggling Act

Software development is still much more of an art than a science. Perhaps one area in which we can apply a discipline more reminiscent of normal engineering is that of understanding and weighing the different aspects of a project. In almost any project, four aspects are critical:

1. The features to be delivered to the users

2. The hardware, software, and other budgets allocated to the project

3. The time frames in which the project phases have to be completed

4. The number of known defects with which the project is allowed to go into production

Balancing these four factors against one another brings us firmly into the realm of classical engineering trade-offs. Concentrating on any one of these aspects to the exclusion of the others is almost never going to work. Instead, a continuous juggling act is required during the life of most projects. Adding a new and complicated feature might affect the number of production bugs. Refusing to relax a specific project delivery date might mean reducing the number of delivered features. Insisting on the removal of every last bug, no matter how trivial, might significantly increase the allocated budgets. So the users, managers, and developers make a series of decisions during the life of a project about what will (or won't) be done, how it will be done, and which of these four aspects takes priority at any specific time.

The major requirement here from the zero-defect point of view is that all the project members have an explicit understanding about the relative importance of each of these aspects, especially that of production bugs. This consensus gives everybody a framework on which to base their decisions. If a user asks for a big new feature at the very end of the project, he or she has no excuse for being unaware of the significant chance of production bugs associated with the new feature, or of the budget and schedule implications of preventing those bugs from reaching production. Everybody will realize that a change in any one of these four areas nearly always involves compromises in the other three.

A project I was involved with some time ago inherited a legacy Microsoft SQL Server database schema. We were not allowed to make any significant structural changes to this database, which left us with no easy way of implementing proper concurrency control. After considering our project priorities, we decided to do without proper concurrency control in order to be able to go into production on the planned date. In effect, we decided that this major design bug was acceptable given our other constraints. Knowing the original project priorities made it much easier for us to make the decision based on that framework. Without the framework, we would have spent significant time investigating potential solutions to this problem at the expense of the more important project schedules. When pointed out in black and white, our awareness of the project's priorities seems obvious. But you'd be surprised at the number of projects undertaken with vague expectations and unspecified goals. Far too often, there is confusion about exactly which features will be implemented, which bugs will be fixed, and how flexible the project deadlines and budgets really are.

Some final thoughts Look at your project closely, and decide the priorities in order of their importance. Determine how important it is for your project to go to production with as few bugs as possible. Communicate this knowledge to all people involved in the project, including the users. Make sure that everyone has the framework in which to make project decisions based on these and other priorities.

Progress Can Be Dangerous

Avalanches have caused about four times as many deaths worldwide in the 1990s as they did in the 1950s. Today, in spite of more advanced weather forecasting, an improved understanding of how snow behaves in different climatic conditions, and the use of sophisticated locating transmitters, many more people die on the slopes. In fact, analysis shows that the technological progress made over the last four decades has actually contributed to the problem. Skiers, snowboarders, and climbers are now able to roam into increasingly remote areas and backwoods. The wider distribution of knowledge about the mountains and the availability of sophisticated instruments have also given people increased confidence in surviving an avalanche. While many more people are practicing winter sports and many more adventurers have the opportunity to push past traditional limits, the statistics show that they have paid a heavy price.

In the same way that technological progress has ironically been accompanied by a rise in the number of avalanche-related deaths, the hot new programming tools now available to developers have proved to be a major factor in the far higher bug rates that we are experiencing today compared to five or ten years ago. Back in the olden days of Microsoft Windows programming (about 1990 or so), the only tools for producing Windows programs were intricate and difficult to learn. Only developers prepared to invest the large amounts of time required to learn complex data structures and numerous application programming interface (API) calls could hope to produce something that even looked like a normal Windows program. Missing the exact esoteric incantations and laying on of hands, software developed by those outside an elite priesthood tended to collapse in a heap when its users tried to do anything out of the ordinary—or sometimes just when they tried to run it. Getting software to work properly required developers to be hardcore in their work—to understand the details of how Windows worked and what they were doing at a very low level. In short, real Windows programming was often seriously frustrating work.

With the introduction of Microsoft Visual Basic and other visual programming tools, a huge amount of the grunt work involved in producing Windows programs has been eliminated. At last, someone who hasn't had a great deal of training and experience can think about producing applications that have previously been the province of an elite group. It is no longer necessary to learn the data structures associated with a window or the API calls necessary to draw text on the screen. A simple drag-and-drop operation with a mouse now performs the work that previously took hours.

The effect has been to reduce dramatically the knowledge levels and effort needed to write Windows programs. Almost anybody who is not a technophobe can produce something that resembles, at least superficially, a normal Windows program. Although placing these tools into the hands of so many people is great news for many computer users, it has led to a startling increase in the number of bug-ridden applications and applications canceled because of runaway bug lists. Widespread use of these development tools has not been accompanied by an equally widespread understanding of how to use them properly to produce solid code.

What is necessary to prevent many types of defects is to understand the real skills required when starting your particular project. Hiring developers who understand Visual Basic alone is asking for trouble. No matter how proficient programmers are with Visual Basic, they're going to introduce bugs into their programs unless they're equipped with at least a rudimentary understanding of how the code they write is going to interact with all the other parts of the system. In a typical corporate client/server project, the skills needed cover a broad range besides technical expertise with Visual Basic. Probably the most essential element is an understanding of how to design the application architecture properly and then be able to implement the architecture as designed. In the brave new world of objects everywhere, a good understanding of Microsoft's Component Object Model (COM) and of ActiveX is also essential. In addition, any potential developer needs to understand the conventions used in normal Windows programs. He or she must understand the client/server paradigm and its advantages and disadvantages, know an appropriate SQL dialect and how to write efficient stored procedures, and be familiar with one or more of the various database communication interfaces such as Jet, ODBC, RDO, and ADO (the VB interface to OLE DB). Other areas of necessary expertise might include knowledge about the increasingly important issue of LAN and WAN bandwidth and an understanding of 16-bit and 32-bit Windows architecture together with the various flavors of Windows APIs. As third-party ActiveX controls become more widespread and more complex, it might even be necessary to hire a developer mainly for his or her expertise in the use of a specific control.

Some final thoughts You don't hire a chainsaw expert to cut down trees—you hire a tree surgeon who is also proficient in the use of chainsaws. So to avoid the serious bugs that can result from too narrow an approach to programming, hire developers who understand client/server development and the technical requirements of your specific application, not those who only understand Visual Basic.

Dancing in Step

One of the most serious problems facing us in the battle against bugs is project size and its implications. As the size of a project team grows linearly, the number of communication channels required between the team members grows factorially (in fact, almost exponentially once the numbers reach a certain level). Traditionally, personal computer projects have been relatively small, often involving just two or three people. Now we're starting to see tools such as Visual Basic 6 being used in large-scale, mission-critical projects staffed by ten to twenty developers or more. These project teams can be spread over several locations, even over different continents, and staffed by programmers with widely varying skills and experience.

The object-oriented approach is one attempt to control this complexity. By designing discrete objects that have their internal functions hidden and that expose clearly defined interfaces for talking to other objects, we can simplify some of the problems involved in fitting together a workable application from many pieces of code produced by multiple developers.

However, programmers still have the problems associated with communicating what each one of hundreds of properties really represents and how every method and function actually works. Any assumptions a programmer makes have to be made clear to any other programmer who has to interact with the first programmer's objects. Testing has to be performed to ensure that none of the traditional implementation problems that are often found when combining components have cropped up. Where problems are found, two or more developers must often work together for a while to resolve them.

In an effort to deal with these issues, which can be a major cause of bugs, many software companies have developed the idea of working in parallel teams that join together and synchronize their work at frequent intervals, often daily. This technique enables one large team of developers to be split into several small teams, with frequent builds and periodic stabilization of their project. Small teams traditionally have several advantages over their larger counterparts. They tend to be more flexible, they communicate faster, they are less likely to have misunderstandings, and they exhibit more team spirit. An approach that divides big teams into smaller ones but still allows these smaller groups to synchronize and stabilize their work safely helps to provide small-team advantages even for large-team projects.

What is the perfect team size? To some extent, the optimum team size depends on the type of project; but studies typically show that the best number is three to four developers, with five or six as a maximum. Teams of this size communicate more effectively and are easier to control.

Having said this, I still think you need to devise an effective process that allows for the code produced by these small teams to be combined successfully into one large application. You can take several approaches to accomplish this combination. The process I recommend for enabling this "dancing in step," which is similar to the one Microsoft uses, is described here:

1. Create a master copy of the application source. This process depends on there being a single master copy of the application source code, from which a periodic (often daily) test build will be generated and released to users for testing.

2. Establish a daily deadline after which the master source cannot be changed. If nobody is permitted to change the master source code after a certain time each day, developers know when they can safely perform the synchronization steps discussed in detail in the rest of these steps.

3. Check out. Take a private copy of the code to be worked on from the master sources. You don't need to prevent more than one developer from checking out the same code because any conflicts will be dealt with at a later stage. (See step 8.)

4. Make the changes. Modify the private copy of the code to implement the new feature or bug fix.

5. Build a private release. Compile the private version of the code.

6. Test the private release. Check that the new feature or bug fix is working correctly.

7. Perform pretesting code synchronization. Compare the private version of the source code with the master source. The current master source could have changed since the developer checked out his or her private version of the source at the start of this process. The daily check-in deadline mentioned in step 2 ensures that the developers know when they can safely perform this synchronization.

8. Merge the master source into the private source. Merge the current master source into the private version of the source, thus incorporating any changes that other developers might have made. Any inconsistencies caused by other developers' changes have to be dealt with at this stage.

9. Build a private release. Build the new updated private version of the source.

10. Test the private release. Check that the new feature or bug fix still works correctly.

11. Execute a regression test. Test this second build to make sure that the new feature or bug fix hasn't adversely affected previous functionality.

12. Perform pre-check-in code synchronization. Compare the private version of the source code with the master source. Because this step is done just prior to the check-in itself (that is, before the check-in deadline), it will not be performed on the same day that the previous pretesting code synchronization (which occurs after the check-in deadline; see step 7) took place. Therefore, the master source might have changed in the intervening period.

13. Check in. Merge the private version of the source into the master source. You must do this before the daily check-in deadline mentioned in step 2 so that other developers can perform their private code synchronization and merges safely after the deadline.

14. Observe later-same-day check-ins. It is essential that you watch later check-ins that day before the deadline to check for potential indirect conflicts with the check-in described in step 13.

15. Generate a daily build. After the check-in deadline, build a new version of the complete application from the updated master sources. This build should be relatively stable, with appropriate punishments being allocated to project members who are responsible for any build breaks.

16. Test the daily build. Execute some tests, preferably automated, to ensure that basic functionality still works and that the build is reasonably stable. This build can then be released to other team members and users.

17. Fix any problems immediately. If the build team or the automated tests find any problems, the developer responsible for the build break or test failure should be identified and told to fix the problem immediately. It is imperative to fix the problem before it affects the next build and before that developer has the opportunity to break any more code. This should be the project's highest priority.

Although the above process looks lengthy and even somewhat painful in places, it ensures that multiple developers and teams can work simultaneously on a single application's master source code. It would be significantly more painful to experience the very frustrating and difficult bugs that traditionally arise when attempting to combine the work of several different teams of developers.

Some final thoughts Split your larger project teams into smaller groups, and establish a process whereby these groups can merge and stabilize their code with that of the other project groups. The smaller teams will produce far fewer bugs than will the larger ones, and an effective merging process will prevent most of the bugs that would otherwise result from combining the work of the smaller teams into a coherent application.