September 18th - September 19th, 2004
Rockville, MD

NEWS

 

Until the Fusebox conference ( September 18th - September 19th), we will be talking with featured speakers at the conference.

Interviews

3. Michael Smith - Real World FLiP

In this Fusebox Conference interview, Hal Helms talks with me, Michael Smith about "Real World FLiP" way to save headaches when developing web applications (Fusebox or other style).

Michael Smith: This week I have invited Hal Helms to invite me about "Real World FLiP".

Hal Helms: What's FLiP and "real world" as opposed to what?

MS:FLiP is the Fusebox Lifecycle Process. It's a methodology for software development that reduces maintenance costs dramatical.

HH: And what's a "methodology", exactly?

MS: It's a fancy word for "method". A methodology tells you how to approach a software project. In other words, what steps to take.

HH: And "real world"?

MS: I mean that we will examine what happens in actual organizations when Fuseboxers try to implement FLiP in their projects. That's as opposed to what you read about FLiP in books, which can be a bit theoretical sometimes.

HH: How are the two different?

MS: Well, in books, there's no opposition to FLiP! In the real world, it can be hard to convince your boss or end-users to use FLiP. Also I have spoken with programmers who have trouble with some of the pieces of FLiP on real projects. That is the kind of issue we will be looking at.

HH: Why do we need FLiP? Doesn't Fusebox do a good job of organizing code and providing focus to software applications?

MS: Fusebox organizes the project code, but FLiP organizes the people and communications on the project. In my experience most project failures are not due to some technical problem, but are caused by people communication problems. For example the client may say they want X. We program Y for them and in reality they need Z! This is scope creep caused by miscommunication. The problem is that clients and programmers speak different languages. Even though both claim to speak English, really clients speak a dialect called "clientese" and programmers speak the "techish" dialect. No wonder we both get confused about what the other person wants!

HH: How does FLiP help solve those problems?

MS: FLiP provides provides tools and processes to allow for communication. That sounds terribly stuffy. Let me try it again: instead of just using more words to try to communicate, FLiP translates those words into wireframes and prototypes. The client tells us something and instead of just making a note and interpreting what the client means at coding time, we produce something for the client to look at, to click through. And we say, "You mean like THIS?" And we keep wireframing and prototyping until the client says, "Yes, THAT is exactly what I mean." It reduces misunderstandings enormously.

HH: So the client actually gets to see the application before it's built?

MS: Exactly. You could think of FLiP like a digital camera with a time machine that can see into the future. That is after all the late night code changes and crazy client phone calls, to a time when (finally!) your application finally does exactly what the client needs. If you could do this and bring the photos back to the present day and link them all together into a clickable website, then that could be your model. Imagine how much coding time and frustration you could save if there were no changes or misunderstandings from having this perfect model available at the beginning of your project. The database could be designed right the first time and you could easily pick out common code to reuse.

HH: What's so special about wireframing and prototyping?

MS: What is special is that they are so simple. I believe that doing things simple is harder than writing something more complex - but is also more valueable. A wireframe is just the skeleton of the site and only shows what pages there are, how they link together and what each page is responsible for doing. There are no graphics or data or real functionality. All this is provided in a website model that the user can click through using one of the free wireframe editors. The ability to test drive the site at the very first meeting with a client is very powerful for communicating about what pages and features are required.

HH: Is there any other benefit to a wireframe?

MS: It also shows up page flow issues or missing shortcuts to key pages too. I find that having an accurate list of pages and features about a site makes it much easier for me to give an accurate time and cost estimate for a site. Think of this process as a blueprint for building a web application. No one would dream of building an office building without plans. Why should we buid complex software without plans either?

HH: What about the HTML prototype?

MS: A full HTML prototype is the next step in filling in the details on the model of the site. It gives all the HTML and graphics for EVERY page in the site EXACTLY as the client needs in the final application. I can't stress the word EXACTLY enough - that is the key to a successful prototype that it lets the client see a "photograph from the future" of their site and give detailed feedback to you on it.

HH: Gee, isn't that a lot of...you know, work?

MS: Well, you're building the front end of your application! That has to be done either now or later during coding. And to the client, the front end IS the application. They just assume that it will work behind the scenes. The question is, do you want to build the front end, getting client feedback BEFORE or AFTER all the code is written?

HH: How do you build the front end without code?

MS: The prototype is pure HTML - no CF code - and so it is very fast to make and very cheap to make changes on.The pages look real, but all the data is dummy data. There's no real functionality and no database behind any buttons (except that the links work and the forms submit to another dummy page).

HH: An iterative approach sounds good, but how will we ever know when we're done?

MS: That is an excellent question and it has to be a combination of both the client and the architect agreeing that the prototype is done. The client says, "You've shown me everything I'm expecting to see on the finished application" and the architect says, "You've given me all the information I need to build this application." I usually provide for a formal sign off of printouts of all pages in the site. It is amazing how getting a client to sign something will freeze any changes until after development is over! I've even had clients who refuse to sign until they get their boss to review the site.

HH: Uggh.

MS: No, not at all. That means that the boss is REALLY the person who has ultimate say. And I'd rather hear what he or she has to say BEFORE all the time and money on the project has been used up.

HH: What's the biggest problem people run into using FLiP?

MS: Getting clients and project managers to understand the benefits of planning out the work before leaping into coding. People are used to seeing instant coding and get nervous when all this communication and thinking goes on. But what I think people forget is that the communication and planning on a project has to happen sometime if we are to deliver a successsful application that satisfies the end-user's true needs. Like I said, the only question is whether this communication is going to take place up front or during -- and even after -- development. In my experience a little education on FLiP at the beginning of a project goes a long way in solving the problem. We will be examining this other common problems in my workshop at the Fusebox conference.

HH: Has TeraTech won any awards for programming or FLiP?

MS: We won the CFDJ award for best ColdFusion consulting company in 2002 and 2003. I think the support we have provided the ColdFusion community helped us win!

HH: Thanks, Michael. We'll look forward to hearing more from you at the conference.

MS: Yes, and don't forget that the early bird pricing ends in the next few days. So people who plan to go should sign up at: www.cfconf.org/fusebox2004/

 

Previous Interviews:
Week 1: Hal Helms - Keynote Speech
Week 2: John Quarto-vonTivadar - New Aspects of Fusebox 4.1

|  HOME  |  DIRECTIONS  |  HOTEL  |  SCHEDULE  |
|  TOPICS  |  SPEAKERS  |  REGISTER  |  CF CONF CENTRAL  |