Most Read This Week
FLiPping the Software Development Process
...and giving clients what they want
By: Hal Helms
Dec. 9, 2003 12:00 AM
In the past, I've written in broad terms about FLiP, the Fusebox Lifecycle Process, a methodology for delivering successful software projects that work (despite its name) with any - or no - software framework. In this article, I want to "drill down" on one aspect of FLiP and see how it is used in practice.
A central tenet of FLiP's philosophy is the recognition that users really can't tell us what they want until they see it. If that sounds paradoxical, consider how often you've delivered a project you've worked long and hard on, only to hear the most dangerous words that can come out of a client's mouth: "You know what would be nice..."
What comes next is a litany of client wishes and needs, followed by the sound of the developer muttering, "Why didn't they tell me this before I built it?" The reason clients don't tell us what they want is that they can't. They have no vocabulary to even think in those terms. Attempts to remedy this using such things as flowcharts and UML diagrams are mostly unsuccessful; clients simply don't think in such structured ways. Instead, they react to what they see, leading to the familiar "you know what would be nice" recitation of wants.
As frustrating as this seems, it can be argued that it's really good news as it provides us with the opportunity - if we accept it - to act not merely as coders, but as developers. Coders are charged with taking requirements and turning them into machine-interpretable programs. Developers are asked to guide the client from the vague stages of "requirements gathering" through deployment. The two have quite different scopes of responsibilities and are paid accordingly.
Back to the paradox: clients can't tell us what they want until they see it, yet we can't build what clients want until we know what we're building. Is it any wonder that the success rate for custom software is so low?
There is a solution to this puzzle, and it's a surprisingly low-tech one. The answer hinges on the fact that to customers, the user interface is the application. They just assume that all that "back-end stuff" will work correctly. (If that seems hopelessly naïve, Alan Cooper, the user interface guru, asks when was the last time you insisted that a new phone you were considering purchasing be plugged in so you could check for a dial tone?) Naïve or not, it offers a way out of the maze: we can provide users with the application - in prototype form.
We often think of a prototype as consisting of nothing more than a few representative pages with, perhaps, some greeking and generic images filling the pages. But a prototype in the FLiP sense is much more like a movie set: its value depends on it being unmistakable for the real thing. Prototypes bridge the language gap between developers and clients by giving us a common referent. We can begin with even vague requirements and depend on an iterative prototype process to help the clients (and us) discover the real job requirements.
In other articles I've discussed how this prototyping/design/requirements process works. In this article, though, I want to start from the point in the development process where we have a fully developed prototype. What then? How do we translate this into something that can be built?
Let's begin by looking at a prototype page. By this point in the process, the client and architect have signed off on the prototype - the client saying, in effect, "Everything you have shown me is just the way I want it, and there is nothing that you have not shown me that I'm expecting," and the architect also indicating that everything needed (content, information, etc.) has been provided. Figure 1 shows what a prototype page might look like.
It's time to move to the architecting stage of the process. From the prototype we need to determine two things: requests that can be made of the application and incoming and/or outgoing variables.
For this, I normally use different-colored highlighters. In this article, though, I've outlined the requests that can be made of the application with rectangular boxes while using ovoid boxes to indicate variables. Figure 2 shows the same prototype page where the process of "marking up" has begun.
If you're using the Mach-II framework (www.mach-ii.com), the requests (javaClassDetails, fuseboxClassDetails, etc.) correspond exactly with Mach-II events. If you're using the Fusebox framework (www.fusebox.org), the requests almost correspond with fuseactions. I say "almost" because a well-formed fuseaction involves both a circuit and a request. In this case, no circuits have been provided. (Even if you're not using any framework, you'll almost certainly have the concept of requests to the application.)
The next phase in the FLiP process is the creation of a schematic diagram. One of the elements of FLiP is the specification of how code should be documented through the use of a fusedoc. While fusedocs provide unit-level documentation (and actually are a form of program-definition language), schematics provide a higher-level representation of the system.
While you can create a schematic with pen and paper, software tools make the process more efficient. At this point in the architectural process, we are still finding our way and tools that allow us to rapidly try out ideas are welcome. One of the best tools I've found for this is known as a mind-mapping diagrammer. Think of it as a visual outliner. Using a mind-mapping tool, I can quickly incorporate the requests identified on the prototype mark-up (see Figure 3).
In many frameworks (including Fusebox), the responsibilities for requests are divided among a series of smaller components. For our purposes, let's assume we're using the Fusebox framework. The next step is to determine which components (circuits in Fusebox parlance) we'll want. One effective method for getting a "first cut" at this is to look for the nouns in the requests. These form a sort of "candidate pool" for circuits. From there, we can exercise our judgment to decide which circuits are the best.
For this application, I've picked out the following nouns as potential circuits: home, training, writings, code, tutorials, newsletter, and consulting. Why nothing for the various class details? I've decided those requests should be handled by the training circuit. Figure 4 provides the mind map with the circuits added in and the requests moved to indicate to which circuits they belong.
With each page of the marked-up prototype incorporated into the schematic, the closer I am to a complete identification of components and requests. Using a mind-mapping tool allows me to easily make changes to my developing architecture. Once the broad strokes are filled in, I can determine the individual bits of code needed to fulfill a request (fuses if using the Fusebox framework) and the incoming/outgoing variables needed for the code pieces. Figure 5 provides a snapshot that shows the fuses needed to fulfill the request, training.trainingInfo. Note the use of the "Comments" section to detail incoming and/or outgoing variables.
When completed, the schematic can be printed or plotted. Some mind-map tools can export the information in outline or XML format while some tools can export directly to Microsoft Office.
What mind-mapping tools are available? There are a number to choose from, with different feature sets and costs. The one I've used here is called MindManager from mindjet.com. Other products include Visual Mind from http://visual-mind.com, MindMapper from http://mindmapper.com, and FreeMind (a free product) from http://freemind.sourceforge.net.
FLiP is a powerful, proven method for repeatedly producing successful software projects that give clients what they want while providing developers with the information they need. Some wag once defined insanity as "doing the same thing over and over while expecting different results." Prototypes and schematics are different tools, integral to the FLiP process, for producing different results. For information on attending a two-day class on FLiP, see http://halhelms.com/index.cfm?fuseaction=training.flipDetails.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads