Interview for Strategies for Successful Development with FLiP
"Strategies for Successful Fusebox Development" interview with Maxim Porges
******************************************************************************
Michael Smith: This time we are talking with Maxim Porges about his CFUNITED-05
talk "Strategies for Successful Fusebox Development". So why should a developer
come to your session Maxim ?
Maxim Porges: First off, hello, and thank you for the opportunity to talk about
my presentation! I had a great time presenting at the 2004 Fusebox conference,
and I'm really looking forward to CFUNITED this year.
To answer your question: a developer should come to my session to save
themselves frustration, time, and money! I think that there are a lot of
developers/development teams out there that have the talent to code phenomenal
applications, but may not have the best process for helping their clients and
developers build the right solution the first time around. My presentation will
show them how to build the perfect application, in one trip, using FLiP (the
Fusebox Lifecycle Process).
MS: "Fusebox" Lifecycle Process... does that mean that you have to use Fusebox
to take advantage of FLiP?
MP: Not at all. You will get all the benefits of FLiP even if you don't use the
Fusebox framework for your coding. After all, coding is only one small part of
the FLiP process - and usually the shortest part of the process, too.
MS: So are you saying that I could use FLiP for a Java application, or with
.NET?
MP: Absolutely! FLiP is an SDLC (Software Development Lifecycle) that can apply
itself to any software project, for any language, and any framework. You would
have the same success using FLiP to scope out a desktop application created in
Java or .NET as you would for an RIA implemented using Flex or Laszlo, or a web
application written in ColdFusion, JSP, PHP, or ASP.NET.
My team likes to build our applications using ColdFusion, but if we started
using C#/.NET tomorrow, or decided to build our applications using J2EE and
Struts, we'd keep on using FLiP as our SDLC. My team has real world experience
using FLiP to build interactive kiosks in Flash, as well as using it for all of
our web projects. I've also put it to use for creating desktop Java
applications.
MS: What is your experience with FLiP?
MP: My team discovered FLiP at the 2002 Fusebox conference. Before we started
using FLiP, we had a lot of trouble putting together applications that our
clients were happy with. It wasn't that we missed requirements; we always built
the client exactly what they asked for. Unfortunately, the client never knows
what they want until they see it, and once you've built something, it's too late
to go back and do things over. FLiP is so good at removing the
client/requirement barrier that my team hasn't had a project fail client
acceptance in over two years.
MS: Wow that is amazing! Is FLiP hard to learn?
MP: FLiP is super easy to learn and use if you do it right. In fact, many
development shops are probably doing most of the steps in FLiP already -
however, they might be doing them in the wrong order, or without the appropriate
level of detail. For example, the process my team was using before we started to
use FLiP had all of the FLiP steps - we just had the most crucial step (showing
the client the application) at the end of the development process instead of the
beginning. It's amazing what kind of impact a small change in your process can
have on your applications.
MS: Does FLiP help you choose which language or framework to use?
MP: FLiP places no restrictions on the language(s) or framework(s) you want to
use to build your solution. Instead, it helps your team and your client
understand the needs for the application as completely as possible, before a
single line of code is written. In understanding those needs, you might discover
that a desktop application will create a better solution than a web application.
I think it's always better if the needs of the application drive the technology
used in the solution, rather than the other way around.
MS: What kind of problems have you seen people have with FLiP?
MP: Although FLiP is quite easy to understand, most people have issues figuring
out how to implement FLiP in practice, rather than how to follow it. For
example:
- What sort of document should you create when identifying Personas and Goals?
- How can you create a good Wireframe?
- How much effort should go in to the Prototype, and how do you create a
formal requirements document from the Prototype for your client to sign?
I could go on and on, but rest assured that I cover all of these items and more
in the presentation. Developers will leave my presentation with a turn-key set of
guidelines to using FLiP right away in their next project.
MS: Do the developers who attend your session need to have an understanding of
FLiP already?
MP: It helps if they have browsed the short introductory page on FLiP at the
Fusebox web site http://www.fusebox.org, but there are no prerequisites to the presentation.
MS: What do you think is the hardest part about using FLiP?
MP: Sticking to the process! FLiP is very easy to follow, but people often want
to skip steps and start coding. I was a programmer before I started managing
projects (and I still write code every day) so I must admit that I prefer coding
over requirements gathering. However, every time my team has skipped a step in
the process, it has bitten us in the butt! On the flip side (pun intended), when
we follow the process properly, the coding is much more fun: we spend our time
writing quality code rather than worrying about details that were missed in the
requirements gathering process.
MS: How do your clients feel about you using FLiP?
MP: Our clients don't usually know what FLiP is, but they always enjoy working
with us - not to mention, 70% of the FLiP process is spent interacting with them
directly! FLiP is very empowering to the client: they drive the requirement
gathering timeline, and have veto power over the way the application looks and
feels, how it flows, and what it does. Usually, our clients can't distinguish
between the Prototype and the finished product, which means that there are no
nasty surprises when the application is delivered. Having a clear idea of what
you are building also allows for developers to create realistic deadlines and
quality code, so the client is always satisfied with the end result.
MS: Are there a lot of people using FLiP?
MP: I don't have any statistics, unfortunately, but the room was filled for my
presentation at the 2004 Fusebox Conference. The best part was seeing so many
people in the session already using FLiP and looking for guidance, rather than
being "sold" on FLiP. When attendees were asking questions about problems they
had with FLiP, they were all the same problems that my team had encountered as
we started out. It was great to get to share our solutions to those same
problems, and to hear the perspectives of the other developers that were present
during the Q+A session.
MS: What else can you tell us about FLiP and your presentation?
MP: There are some fantastics tools out there for FLiP, many of which were
demoed at the 2004 Fusebox Conference. We use Adalon on my team, which we love,
and I've heard great things about Fusebuilder on the Fusebox forums (just to
name two). Plus, there are great books about FLiP authored by members of Team
Fusebox if you want to get in to more detail.
Finally, I'm honored to have Jeff Peters and Sean Corfield as my presentation
buddies. We got our first taste of FLiP in Jeff's presentation at the 2002
Fusebox Conference, so in many ways we owe our success to him! And of course,
Sean needs no introduction as one of the sharpest minds in the community. With
Jeff and Sean on board, I'm sure we'll have a great Q+A session following the
presentation.
MS: That is great - see you at your session!
|
|
