Archive | December 3, 2003

On February 23rd, 1999, I completed a several months on-site consulting gig, packed up my desk and moved along, back to the consulting firm I worked for at the time. During the last week I was there, I composed an email summarizing the challenges I had run into. Some had been addressed, others continued. Several recent encounters online and with clients old, new and prospective brought the essay to mind again. Here it is:

1. Design First, Code Second. There’s an old joke of the salesman poking his head into the computer room and announcing “I sold the client on the system! You guys start coding, and I’ll go find out what they want.” Too true.
   • design the data schema. Review the schema for the levels of normalization. Review again as objects, forms and walkthroughs talk about touching the data. Make the schema available to everyone, but maintain control of changes.
   • design the objects. Input, output, process and sequence of events can be defined to meet the needs of the system.
   • design the forms. Review them with the client, preferably with the operators. Seeing a prototype user interface uncovers awkwardnesses, identifies additional elements that need to be added, and invests the client with ownership of the design. Walk through the system, as in use cases. These walkthroughs determine the workflow and the data flow and often uncover inconsistencies in the interface and data design.
   • document the system. The documentation should be a user manual that describes normal and exceptional use of the forms. The client needs to sign off on this as what they want the system to do. This document should be (a) programmer documentation on what the form is to do, (b) testing documentation on what to test, (c) user documentation on how to use the forms.
   • give ownership of the components to individuals. Review and walkthrough the design with all participants to ensure each understands the responsibilities and behaviors of their components.
   • coding before the design is complete is dangerous. Programmers get attached to their creations, and resist attempts to change it by making ludicrous kludges and awkward extensions. Initial coding should be for prototype, throw-away use, and to determine feasibility of new techniques and technologies. Encourage everyone to “code it and throw it away” because they will.
2. Test, test, test. The criteria for a form being complete is that it passes a series of tests that describe the paths that occur in data entry. An untested form is not done. Programmers cannot test their own forms. Unit test and integrated testing need to be managed by a tester.
3. Standardize. Determine the ‘right’ way to select, multi-select, add, edit, delete and implement them consistently throughout the user interface. Standardize on a framework, a naming convention, a calling convention, an error handling method. Document these standards and ensure that all members of the team have read these and agreed to follow them. Make them available to the team during the process, and use them as a guide to perform code reviews, walkthroughs and audits.
4. Get out of the way and let the coders code. Give them the tools they need, the interruption-free time, the speed to do their jobs. Powerful computers, access to training materials, free soda, whatever it takes.
   • train the programmers on the system they’ll use – framework, standards, etc.
   • source code control helps in disaster recovery.
   • code reviews keep programmers on their best behavior
   • code walkthroughs ensure quality
   • cross-training improves programmer knowledge, allows transitions of programmers, and improves code.
5. Coders: Be one with the Fox. There are lots of cool and clever things you can do with FoxPro, like firing UDFs in grid controlsources, or UDFs in DynamicBackColor, or assigning data bindings in classes. But just because you _can_ do something, doesn’t mean you should. Understand what works well in VFP, what’s the optimal choice, and what you should resort to only in desperate circumstances.