In The Beginning  - Fox Pro

Everything in life has a beginning-a point where the details are ill defined. Application development is not any different. All projects have a beginning; the actions we take and decisions we make at the beginning will heavily influence the rest of the project. In this chapter we'll look into the beginning of application projects and find some ideas on how to make them work for us instead of against us. This chapter is not a treatise on Object Oriented Analysis and Design, but rather a pragmatic discussion of some ideas that can help that process to be more fruitful.

Finding out what needs to be done

The first order of business is to get a clue! Get some idea what the project is about. This may seem obvious, but it isn't. There are two sets of ideas about the project: the developer's and the client's. These two views are seldom the same.

We are developers so we can understand the developer's need to gather details about the functional requirements, how many forms there will be, how many data tables are needed, how the tables relate to each other, and all those other things developers need to know.

However, clients often see the project in a very different way. A client has pain! Something is wrong in their business. Perhaps a competitor is beating them in the marketplace, or they're losing inventory through shrinkage and can't track it down. Maybe the cost of sales is too high and profits are being hurt. Or it may even be that the company is growing at a very rapid rate and they sense a loss of control over their costs.

Whatever it is, the client has a problem that is causing them pain. They aren't hiring us to build great software; they are hiring us to relieve their pain. If we want to succeed with the project, then we must focus on relieving the client's pain. To do that we must understand the pain and where it's coming from.

What do we know?

We know about building applications. We know how to make computers sing. We can tweak the last nanosecond out of those SQL queries. We know how to protect the referential integrity and enforce the domain constraints. We can validate fields, rows, and even whole tables.

All of these things are important to a successful project; however, we're totally off base thinking that the client cares about these issues at all. The client cares about finding the shortest route to pain relief.

What does the client know?

The client knows that they are in pain; they may or may not know the exact cause of their pain. They know how they run their business. They know their market and their customers. They know what their customers want. They know how to build their product or provide their service.

The client is human and likes to feel important and intelligent. If we start out by forcing them into a structured analysis of their business, we're putting them into an uncomfortable situation where they don't know the jargon and they're unfamiliar with the processes. Human nature says they'll do everything in their power to shorten that experience as much as they can.

Herein lies the conflict

We have been told time and again that solid analysis and design are critical to a solid application. This is simply a truth of nature. We also know that clients see the analysis and design phases as wasted time. They see it that way because nothing new is showing up on their computers. They also see it that way because the process is a nightmare for them. They feel inadequate and unintelligent.

What can we do to change this? How can we get the client to buy into good analysis and design? We can do it by not telling them that's what we're doing, by dumping the jargon and the fancy forms and checklists (oh, we'll use them, but not in front of the client-at least not at first).

Start the analysis by saying something like, 'This system is going to need to work well within your business and I'm not anywhere near knowledgeable enough about your business to accomplish that. I'll need your help and your expertise to deal with the business side of this project. Can you describe the nature of your business for me?'

Let these early conversations be loose and descriptive of the client's overall business. Take copious notes. Retire from these early meetings and analyze your notes. Then write a few pages of summary, in English, describing what you understand. Return to the client and ask them to read the summary and let you know what you've got right and, more importantly, what you've got wrong.

After one or two go-arounds with this, you can start bringing out the checklists and the other fancy charts and diagrams. Introduce these documents slowly and explain their structure. Work slowly into the details of the information contained within the documents.

By following these few ideas at the very beginning, you'll be better able to get the client to buy into the analysis phase (without them even knowing that's what they did) and you'll probably get much better and more complete information from them.

Having a plan

Once the analysis is fairly complete and you have a good, solid foundation of understanding both the project requirements and the business in general, you can begin to make a plan for the project. The early design is that plan.

You wouldn't consider leaving on a two-week vacation without having any idea of where you were going or how to get there. A vacation that starts that way is surely going to have problems. No, you would select a destination or two and then review the maps to plan the best route. You might vary from your plan during the vacation, but you wouldn't start without a plan.

Project development is the same way. You don't want to start without a plan-some kind of map of where you're headed and how you intend to get there. Without a plan, you'll likely travel down many dead-end roads and have to dump the work and start again.

Having a design doesn't mean that you won't alter it during the development; you most certainly will. You'll discover information or learn something new about your tools that will cause you to alter your plan. That's fine. It even has a name: it's called iterative development.

Your plan should include class designs for those objects that you'll be using, your data design with the persistent relations defined, user interface design, report design, and other things. There is no law that says you cannot use Visual FoxPro to accomplish these designs. You can use the form designer to lay out the forms and the user interface, the database designer to lay out the tables and relations, and the report designer to lay out the reports. The issue is that you don't want to spend a lot of time filling in the details at this stage. Why not? Because things will change. It is much easier to redo a form that has little or no code in it, than to feel the cramps of throwing away two days of work on a form that just does not fit.

Iterative development

The processes of Analysis, Design and Implementation are almost always shown as a timeline, where one process does not begin until the previous one is completed. This isn't how it works in the real world. We analyze the information until we have a degree of understanding; then we begin to design the application. Often during the design, questions will arise that cause us to go back to the analysis and get the answers.

When our design is fairly well laid out, we begin building the components that will comprise the application. This process inevitably will uncover weakness, omissions, or outright errors in our design, which cause us to stop and return to the design to alter it.

The one mortal sin for any developer is pride of authorship. Pride of authorship will cause us to resist scrapping something that isn't quite right. We'll twist, pry, sweat, hammer, squeeze, push, pull, bend, spindle and mutilate that thing to try to get it to work. The longer we beat on it, the higher the degree of pride of authorship and the more difficult it becomes to finally let go, scrap it, and start over again.

Whenever you find yourself even remotely considering starting something over, remember this: IT WILL NEVER GET EASIER TO START OVER THAN IT IS RIGHT NOW; IT WILL ONLY GET HARDER.