Digital Edition

SYS-CON.TV
FLiPping the Software Development Process
...and giving clients what they want

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.

About Hal Helms
Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1



ADS BY GOOGLE
Subscribe to the World's Most Powerful Newsletters

ADS BY GOOGLE

ChatOps is an emerging topic that has led to the wide availability of integrations between group cha...
As DevOps methodologies expand their reach across the enterprise, organizations face the daunting ch...
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being soft...
You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know ...
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every ...
The cloud era has reached the stage where it is no longer a question of whether a company should mig...
The need for greater agility and scalability necessitated the digital transformation in the form of ...
In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an over...
Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection...
In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and ...
While some developers care passionately about how data centers and clouds are architected, for most,...
"Since we launched LinuxONE we learned a lot from our customers. More than anything what they respon...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily ...
"As we've gone out into the public cloud we've seen that over time we may have lost a few things - w...
In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Ser...
Sanjeev Sharma Joins June 5-7, 2018 @DevOpsSummit at @Cloud Expo New York Faculty. Sanjeev Sharma is...
We are given a desktop platform with Java 8 or Java 9 installed and seek to find a way to deploy hig...
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis too...
"Cloud4U builds software services that help people build DevOps platforms for cloud-based software a...
The question before companies today is not whether to become intelligent, it’s a question of how and...