The Authors

Each author was selected to participate in this book based on their varied deployment experience and development expertise. The three authors have a combined 36+ years of experience deploying FoxPro and Visual FoxPro applications and even more years deploying applications with technologies from hand held computers all the way up to the big iron mainframes and numerous platforms in between.

Rick Schummer

Wrote Chapters: 1-4, 6-10, E, F

Tech edited all of Rick Borup ‚ s chapters and Jacci Adams ‚ chapters (except for 11).

I have been deploying software since 1983 and FoxPro applications since 1989. My first deployment was a banner creation program I wrote for myself in ‚“Extended Basic ‚½ on the TI- 99/4A while in college. I showed the program to a couple of friends who encouraged me to deploy it as shareware. I wrote a user guide, polished it up, and released it ‚“into the wild ‚½ via a local bulletin board in the Detroit area. I received one $5 registration from a person in California, my first nation-wide deployment. Maybe not very successful financially , but I knew at least two people were using the package besides me (the other person was someone I met at a local user group who never registered). Since that time I have deployed COBOL applications on mainframes, reports generated using FOCUS, numerous Fox applications from FoxBase to the latest Visual FoxPro, and even some Internet applications using Active Server Pages and WebConnect. I have been a project manager with projects deployed in Lotus Notes, Microsoft Access, Visual Basic, and have had several project experiences/frustrations where the development never deployed. The majority of my FoxPro experience was developing applications deployed in General Motors, their financing subsidiary General Motors Acceptance Corporation (GMAC), and their insurance subsidiary Motors Insurance Company (MIC). Our applications ran in 300 sites around the United States and Canada, and in several countries in South America. Since leaving EDS, I worked at a small company where I had several new experiences that led me to partner with two geeks at Geeks and Gurus, Inc., which led me to start my own company, White Light Computing, Inc. All totaled, 20 years of deployment and 14 years with FoxPro has given me a few stories to share.

My best experience is a fun little one-night project. Patty Nowak and I were in Buenos Aires, Argentina trying to find a serious bug in our FoxPro 2.5 for Windows application. It took 4 days to do the research and make the fix. The night before we left to come home, we had dinner with the branch manager and asked a simple question: ‚“What is the one thing you wish you could have in your application? ‚½ He detailed a collections module that displayed the deadbeat customers three times a day in a queue so his collections department could call and offer a ‚“friendly reminder ‚½ to pay their bills. Dinner in Argentina starts around 10:00pm and we went back to the hotel after midnight. At 4:00am I left a diskette with the new module on my room door in a bag. Patty picked it up, went into the branch, and tested the code. She gave me a wake up call with a short bug list and I fixed them early that morning. We did more testing, put together a training plan, and trained the users late in the afternoon. While the training was underway, the branch manager pulled me aside to ask how long we had been sandbagging the feature. I told him I developed it the night before, after dinner. He was shocked as it took the mainframe staff two years to add the equivalent feature for the same module in the legacy application. We flew home on a plane totally energized by the experience. The lesson learned was: surpass your customer ‚ s expectations and they are customers for life.

My worst experience happened a couple months out of college. I made some minor changes to a program that transferred data from 8 sites around the country to the Burroughs world headquarters where I worked. This was critical information for the company ‚ s management to make decisions on supporting customers. I thought I tested it, but something went very wrong, the tapes were not generated, and plenty of managers were anxious to get their reports the next morning. My manager was sitting on my desk when I got to work. His only words were ‚“Fix it, test it, deploy it, and get the < bleeping > tapes here by the morning or else! ‚½ I had one little bug that testing should have caught. I had to fix it, test it in house, deploy it, and test it onsite before the batch process ran that afternoon so the tapes could be sent overnight to our offices. I was crunched for time and under the distinct impression that I was going to be fired . Several of the managers who did not have their data were kind enough to stop by my desk and vent their frustrations. I found the bug, did the appropriate testing, and made a successful deployment. Lesson learned from this experience was direct from my manager the day the tapes arrived: if you want to make a name for yourself in this business, write the killer app of all time, or screw up royally once. I took the easy route. He was impressed by my recovery, did not fire me, and was one of the best managers I worked for in my career.

Rick Borup

Wrote Chapters: 5, A, B, D

Tech edited all of Rick Schummer ‚ s chapters and Jacci ‚ s chapter 11.

I ‚ ve been developing and deploying software in one form or another since 1971. During the 70 ‚ s and 80 ‚ s I was employed writing business software programs for IBM and Unisys (Burroughs) mainframe computers. During that time, I also did a fair amount of data communications work and some systems programming, too. When PCs came along I dabbled in dBase and R:BASE and began to appreciate the power of a database development tool. I discovered FoxPro around 1991 and have worked with it full time since 1993.

Back in the mainframe days, I didn ‚ t give much thought to deployment. Like most other programmers at that time, the software I wrote ran on computers that operated in a highly centralized environment. As a programmer/analyst my job was to design a program or a program enhancement, write the code, and test it. Deployment typically consisted of nothing more than notifying the computer operator that a new version of a program was ready to go into production.

PCs changed everything. Even in the early days, PC software deployment presented new challenges because every PC within the organization needed its own copy of the software, and of course, there were a lot of PCs. To make matters worse , each PC came with a ‚“user ‚½ instead of a trained operator, and many users just plain didn ‚ t want to know any more about computers than they absolutely had to. A typical deployment scenario went something like this: (Phone rings) Me: ‚“Hello? ‚½ User: ‚“How do I install this new software? ‚½ Me: ‚“Insert the diskette we sent you and type A:setup at the C: prompt, like it says on the label. ‚½ User: ‚“What ‚ s a C: prompt? ‚½ Me: ‚“(Sigh) We ‚ ll send somebody right over. ‚½ Deployment was already becoming problematic .

Today, deployment and deployment planning are a significant part of the overall software development effort. Over the last several years deployment has emerged as its own legitimate field of expertise, adding yet another layer to the skill set each of us needs to possess in order to provide effective solutions to our customers. That ‚ s one of the reasons I was so excited about the chance to work on this book.

My best deployment experience occurred over an Easter weekend several years ago. The bank I worked for at the time had acquired new teller machines scheduled to be installed on Saturday. Today tellers often use PCs, but back then they used special purpose teller machines to process over-the-counter transactions. These machines were vital to the daily operation of the bank because without them the tellers couldn ‚ t cash checks, accept deposits, look up balances, or print receipts. The new machines arrived in good physical condition and we started to roll them out on Saturday morning. The first sign of trouble came when we discovered the machines wouldn ‚ t communicate with our central communications controller. This was critical because each teller transaction had to be sent via the communications controller to the mainframe computer, which verified balances before authorizing withdrawals and updated balances after accepting deposits. It didn ‚ t take long to determine the communications software in the new teller machines was incompatible with our controller.

Gut check time! I ‚ ve forgotten some of the details by now, but what it came down to was that I had to write a communications protocol program ‚ think of it as a device driver ‚ to run the new teller machines, in one day, starting from scratch, and with nothing to go on except the encouragement of my boss and whatever information we could get from one guy on the other end of a long-distance tech support phone call to the vendor. Needless to say, it was a long phone call and a long weekend. Nonetheless, by Sunday afternoon, I had the program completed and tested, and everything ran smoothly when the bank opened for business on Monday morning with all of its new teller machines in place as planned. I still feel good about that one!

Maybe I ‚ ve just been lucky, but I can ‚ t really think of a case I would describe as a ‚“worst ‚½ deployment experience. One experience that does come to mind, though, occurred with one of the first FoxPro applications I ever deployed commercially. The app was written in FoxPro for MS-DOS and designed to run in a multi-user environment on the customer ‚ s local area network. I read everything I could about designing for multi-user environments, and although I did not have a network in my office to test on, the app ran fine on my development machine. (Did somebody say, ‚“Famous last words? ‚½) When deployment day arrived, I was feeling pretty confident I had covered all the bases as I loaded up the app on a set of diskettes, drove over to the customer ‚ s office, and copied everything to the file server.

One of Murphy ‚ s Laws is that things are more likely to go wrong when the customer is looking over your shoulder, and of course, that ‚ s what my customer was doing that day. This was his first chance to see the finished product, and I knew my reputation ‚ not to mention my fee ‚ depended on things working as advertised. We fired up the app from the first workstation and everything ran fine. Then we started up the app from a second workstation, and my confidence faded when the error message ‚“File access denied ‚½ appeared on the screen. Did I mention that the client was looking over my shoulder? ‚“What file is it talking about? ‚½ he asked. ‚“I don ‚ t know, but I ‚ ll find out, ‚½ I said, with little idea of where to even start looking. My customer, who had confidence in me even if my own was momentarily shaken, walked away to attend to other things and gave me time to work on the problem without interference. Thank goodness for great customers like that!

It took a while to figure out what was happening, but I eventually did. Some of reports in this app printed special forms on laser printers, so the app needed a FoxPro resource file that contained the printer driver setups (remember this was a DOS app). This resource file was the same for all users, so I had put it on the file server along the EXE. With one user this worked fine, but it turned out the second user was locked out of the resource file by the first user. The solution was simply to set the Read-only attribute on the resource file. After doing this, the app ran fine for multiple users and the day was saved. It ‚ s an experience I ‚ ll never forget, and this tiny but important step immediately became part of my deployment checklist for future apps.

Jacci Adams

Wrote Chapters: 11, 12, C, and G.

First and foremost, I ‚ m not an attorney nor do I play one on TV. Chapters 11 and 12 deal with legal issues, these chapters are here to be thought provoking not legal advice. Some of what ‚ s written may be different from what you ‚ ve been told or heard . This is why I can ‚ t stress enough that you contact a computer law attorney in your state or country if you have questions or concerns.

Now you know who I ‚ m not, here ‚ s who I am. I am a developer with 18 years of experience developing and deploying custom database applications. I started my software development career in 1986 at the Gaithersburg, Maryland office of the Bechtel Corporation, the company that participated in the construction of several well-known projects including the San Francisco Bay Bridge, the Hoover Dam, and the Alaskan Pipeline. My title was Electrical Engineer, but my primary responsibility was to develop in-house tracking applications using dBase II and III. We tracked people, resumes, radiation levels, and timecards. My next career move was out of my hands. I spent the next 4 years battling Hodgkin ‚ s disease ‚ nine months of chemotherapy, got married during a 9 month remission, another 6 months of even higher dose chemotherapy, eighteen months of remission, and then an autologous bone marrow transplant . I was at the hospital so much and got to know the staff that I eventually met the research director who had a small stipend to develop a neonatal database using FoxBase+ Mac. The hospital didn ‚ t take any taxes out of my pay so, voil ƒ  , I ‚ m an independent software developer. I learned the independent consulting business by trial and error. Thank goodness for the CompuServe forums. I had eleven very successful years doing business as Lindsay- Adams Consulting deploying FoxPro 2.6 and VFP client-server applications. Then the economy took a nosedive as did my client base. I decided to take a stab at becoming an employee last year, but it didn ‚ t work out well. We had conflicting software development and deployment philosophies. So, I ‚ m back to being an independent FoxPro and .NET application developer specializing in custom scientific, engineering, and medical database applications.

I used to be one of those people who thought deployment was synonymous with creating the installation/distribution disks. Well, working on this book has been a real eye- opener . I ‚ m using the knowledge I gained from working on this book to create even better software deployments for my clients .

My best deployment experience was for Diebold, Incorporated ‚ s Direct Marketing department. I developed a client-server customer satisfaction survey. They made my development and deployment effort a breeze . They knew what they wanted. I designed and coded the application. They had part of their staff test it before deploying it to the entire staff. Testing went well. Installation on all of the user ‚ s systems went well. The end user feedback was very positive. The managers were very happy about the reports they were getting. This application evolved from a FoxPro 2.6 Windows application to a VFP 6.0 application using COM automation with SPSS to create statistical reports for their Quality Assurance experts. I was told the SPSS reports had significant impact on the business areas they were focusing their attention on. I had a 5-year relationship with them and survived 5 major staff turnovers. Now, if only all projects and client relationships could go that well.

My worst deployment experience came at the time I was transitioning from FoxPro DOS to VFP (I never really did much FoxPro for Windows. I spent about 3-4 years working on a Fox 2.6 Mac application). I was in a time crunch to get a prototype done in VFP. I was very excited and nervous at the same time because it was my first VFP 3.0 prototype application for a potential new client. I wasn ‚ t very familiar with the distribution process because all I had ever done was copy all the files to a floppy or network drive and that was it. This time was different ‚ well not really. I did what I always did, copied all the files to a floppy, and sent the disks to the client. Well, you can guess what happened ‚ it didn ‚ t work. The potential client wasn ‚ t very happy and I didn ‚ t get the contract. Good news for me now that I ‚ m developing .NET web applications, all I have to do is XCOPY (...yeah right).