Each week from now until the Fusebox conference (Aug
31 - Sep 1), we're talking with one of the conference speakers.
WEEK 2: Michael Smith
FB: This week, we're talking with Michael Smith,
the president of the award-winning development firm, Teratech.
Michael, you're speaking on "Real World
FLiP". What's FLiP and "real world" as opposed
to what?
MS:FLiP is the Fusebox Lifecycle Process. It's a methodology
for
software development.
FB: 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.
FB: 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.
FB: 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.
That
is the kind of issue we will be looking at.
FB: 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!
FB: 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.
FB: So the client actually gets to see the application before
it's built?
MS: Exactly. You could think of FLiP like a digital camera
into the
future, after all the late night code changes and crazy client
phone
calls, to a point when 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.
FB: What's so special about wireframing and prototyping?
MS: 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.
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?
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.
FB: 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. 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?
FB: 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.
FB: 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.
FB: 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.
FB: 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.
FB: Has TeraTech won any awards for programming or FLiP?
MS: We won the CFDJ award for best ColdFusion consulting
company in
2002. I thinkthe support we have provided the ColdFusion community
helped us win. We are nominated again this year and we'd really
appreciate the community's support by voting for us at:
http://www.teratech.com/vote.cfm.
FB: 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/fusebox2003.
//
Next week: Jeff Peters talks about Fusedocs.
Previous weeks:
Week 1: Ben Edwards
Week 3: John Quarto-von Tivadar
Week 4: Hal Helms
Week 5: Jeff Peters
