LA Fox Presidents Column

The LA Fox Developer Newsletter

The LA Fox Developer is the monthly newsletter of the LA Fox User Group. The purpose is information sharing among application developers and users working with FoxPro.

Harbor City, CA 90710

LA Fox Board of Directors

Chuck Williams, President

David Van Valkenburg, Treasurer

Allen Garfein, Membership

Barry Lee, Newsletter Editor

The newsletter contains regular columns and articles from other user groups.

2210 Wilshire Blvd. - #161

Santa Monica, CA 90403

OC MS FoxPro Developers Group

The annual membership fee for the LA Fox

User Group, including subscription to The LA

Fox Developer Newsletter, is $45.

Neither the LA Fox User Group, the XPro User Group, the OC MS FoxPro Developers Group, their officers or board of directors or their members make any express or implied warranties of any kind with regard to any information disseminated, including, but not limited to, warranties of merchantability and/or fitness for a particular purpose.

Opinions provided by newsletter articles, or by speakers, members, or guests who address the meetings, are individual opinions only, and do not necessarily represent the opinions of the group. All opinions and information should be carefully considered, and the group is not liable for any incident or consequential damages in connection with, or arising out of, the furnishing or use of any information or opinions. Brand names and product names may be trademarks or registered trademarks of their respective owners.

“waterfall” model of development and the rapid prototyping approach. One of the major shortfalls of the traditional approach is that the real users never see anything until the specification process is complete and development is well under way. As Jim pointed out, this often doesn’t work well because users are not good at describing what they want and need unless they can see it on screen and use it, so this almost guarantees a large conflict between developers and users when users finally see some tangible results. Rapid prototyping, on the other hand, puts working screens in front of the user very early in the process, and allows the “requirement” to evolve to something closer to what users really need, before there is a big investment in developer effort and calendar time. This pays particularly big dividends in client-server systems, by achieving stability in definition of the backend database structure before starting to build the many interrelated data objects and backend-frontend connections.

Jim stressed the use of simple diagrams as a way to communicate with users. He cited examples where reducing the “requirements” to diagrams, not only clarified the situation for developers, but also created great diversity of opinion within the client organization about how their world really worked.

Jim shared his ideas about naming conventions, and said that the most important thing was to have one, rather than what its details are. He encouraged the “black-box” idea, where segments of code associated with a particular action are isolated by such techniques as privatizing variables, to avoid invisible interactions with the application environment, and to create clear visibility to the designer. He said that “optimizing” should not always favor performance, but should consider clarity, development effort, and maintenance effort performed when the original designer is gone. He also cautioned that sometimes added complexity in the short term or narrow code segment is worth it to simplify things in the larger application context.

Anyone who didn’t learn something useful in this session must have been asleep. Thanks Jim for sharing with us.

And, fitting right in with this theme, the latest book in the Pinnacle Pros Talk Fox series just arrived, with the title FoxPro Rapid Application Development. The author is Whil Hentzen, another long time Xbase developer and frequent writer and speaker at FoxPro events. He describes in detail his approach to establishing a productive development environment and using Core Foundation elements. His environment ideas include defining directory structures and managing test data. His Core Foundation is a superstructure containing generic elements for the “main” initializing program, menu handling facility, error trapping, help facility, security facility, lookup tables, and