CFUNITED 2007 Website
 Receive our newsletter   about | contact us | home  
Interview Page

"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!