These patterns talk about how you begin developing a system. How do you learn what you need to from the client without alienating them? How do you make sure your understanding is consistent with the needs of the program? How do you accept and take advantage of the inevitable changes in your client's thinking? The patterns are:
1. Story
2. Early Program
3. Architecture Prototype
4. Interface Prototype
<What patterns are upstream of Story? Must be something about deciding to computerize something.>
How do you start development?
Unless you are already an expert in the field, as a software engineer you need to begin to understand your client's area of expertise before you can begin making decisions. Somehow, you need to learn enough to get going.
Some engineers begin development with a software mind-set. They begin diagramming or even programming as soon as the client begins talking. As you will see in Early Program (2), I believe in beginning to program early in the process, but the client has to drive the process at first. If you begin with the mapping of desires to possibilities too soon, you risk missing the real point of the desires. Often, your client will say subtle things in the first few minutes that can have enormous impact on the development. If you are too busy figuring out whether you have a 1-to-1 or 1-to-n relationship, you will overlook these nuggets.
Other engineers take the opposite tack. They want to gather all the requirements before development begins. I call this "use case paralysis". The notion that there are "requirements" that can be "gathered" has killed more software projects than any other. It's like trying to bake a cake before you've mixed the ingredients. The presence of the system, even the presence of the process of building the system, changes the client's perception of their world. Better to recognize the way the world works, and adapt to it, than to continue wasting time, money, and energy chasing a will-o-the-wisp.
Another factor that enters into the decision of how to get informed about the client's expertise is the natural human need to feel heard. Software development is often disenfranchises the client. Whatever they were doing before is about to change forever. But without the willing participation of your client, you can never be successful. How can you get someone who is about to be screwed to help you with enthusiasm?
Finally, recognize that you will never truly become an expert in your client's field, unless you stop looking at it through the eyes of a software engineer. No matter how well you learn to talk the talk, you still won't walk the walk. Fortunately, it is not important to be an expert to write effective software (already it is probably necessary to be an expert to write great software). You only need to know enough to map your client's desires to the capabilities of current computers. In the beginning, you only need to understand enough to get the evolution of the system rolling.
Therefore, ask your client to tell you a half a dozen stories about how the system will be used. Ask them to think about the moral or point of each story before they begin telling it. Record the stories for later transcription. Don't ask too many questions while you are listening, unless you are hopelessly lost.
You need Early Program (2) to test your understanding and begin the process of evolution.
You have a handful of Stories (1) that decribe how the system should feel.
What do you do to begin mapping what the client wants into software?
Some developers begin casting their client's desires as software in the abstract. They use a CASE tool to draw diagrams that represent the client's domain. Then they use a CASE tool to draw diagrams that represent the software. Finally, they allow the program to be cast in executable form.
I think that this abhorence of running software comes from the early days of large scale software development. It wasn't far into the history of programming that it was obvious that just sitting down and programming wasn't enough. Programmers without the discipline to take a more structured approach were looked down on. "Oh, he's just a hacker."
What is the problem with early code? In the early days of programming styles, languages and environments, it was common for assumptions to permeate the entire program. These assumptions formed enormous inertia against change. Thus, decisions made early in ignorance were extremely costly if they turned out to be wrong.
What is the problem with abstract representations of the client's desires and the software which realizes them? Simply, it is far too easy to bullshit about the quality of the software, the degree to which it pleases the client, and how far along it is. Thousands of pages of analysis and design diagrams can easily mask the fact that no one know how, or even if, the whole system works.
System development needs some objective measure of the progress. Diagrams have a strong role to play in communicating the structure and intent of the system at all phases. Relying solely on diagrams is begging for trouble.
But what about the problems with early programs? Aren't they written in ignorance of the eventual needs of the system, invoking the inordinate costs pointed about above? Many things have changed since the days when a program was a monolith to be altered only at the sacrifice of all you held dear. Programming languages have developed abstractions like polymorphism and garbage collection which effectively insulate parts of the program from changes in other parts. Programming environments with support for large system development ease the mechanics of making and verifying changes. The final piece of the puzzle of reducing the cost of code changes, the factor which makes early code more than worthwhile, in fact makes it essential, is pattern guided development. Programming style based on patterns ensures that all parts of the program keep an appropriate eye on future evolution, and the nothing will be done to gratuitously hinder changing the code.
The combination of these factors- language, environment, and patterns- creates code which is not expensive to change, even radically. Thus, as new insights come to light, they can be incorporated into the running system quickly and at minimal cost. The advantages of concrete, running software are overwhelming if there is no great price to pay.
Therefore, build concrete software that shows how the system executes the Stories.
If you are working in a group, you may want to build simulated software first with CRC (?). A technically literate client can understand an Architecture Prototype (3). A client who is more visually oriented might profit from an Interface Prototype (4).
You need to write an Early Program (2).
What kind of program should you write early in development?
Early in a project the client and the developers are both looking at a distant object through fuzzy telescopes. The real question is, which telescope do you focus first?
There's lots to recommend prototyping the client's view of the system, the user interface. It is the one point in the system where the client and the developer are looking at the same thing. For clients and developers who aren't communicating well, prototyping the user interface can give them enough common ground to stand them through the rest of the project.
The major argument against user interface prototyping is that it prematurely raises the client's expecation of what is possible. As soon as they see something that looks like the system, they will assume the rest is done. Clients who aren't familiar with software development can get quite belligerent when told that even though the pictures look finished, the software is only 5% done.
The other important aspect of the system to decide on early is the architecture- the major components, their distribution of responsibility and flows of control. The architecture is the common ground for the whole development staff. Until the team shares a vision of the architecture, little real progress is made. Actually, code that is written in the absence of an architecture may slow further development.
Therefore, write a tiny system which communicates the important shared responsibilities to developers. Give each object no more than a handful of methods. Optimize readability over flexibility.
Begin the system with a User's Object (?). Document the prototype with a Literate Program (?).
You need to write an Early Program (2).
What code do you write early in development?
Some developers are so focused on how they are going to make the system work that they are unable to take a step back and understand the system from the client's point of view. They tuck what little understanding they have of the client's domain under their arm and run with it. Systems developed in this environment are often technically beautiful but useless, providing no payback for the development investment. The developers need to "walk a mile in the client's shoes".
Clients often have the opposite problem- they are so focused on the grand and glorious future that they are unable to focus on what to do first. Symptoms of this disease are system concepts that never get more specific than a handful of bullet items or architecture diagrams drawn by non-technical clients. Systems with unfocused clients go through wild thrashing early in their lives. The client needs to set priorities.
Therefore, write the user visible portion of the system required to support the most important Story (1).
You will need to build a User Interface (?).