At last night's New York ColdFusion User Group (NY-CFUG), Clark Valberg of Epicenter Consulting gave a most excellent presentation on what he refers to as the "Interface Driven Architecture Methodology." For a very brief summary, he basically breaks up the development life cycle into two different phases: Design and Fabrication. In this model, absolutely all interface design is prototyped and finalized by the client in the Design phase before any "coding" is done. Then, in the Fabrication phase, all prototypes are implemented including a functional code base.
I happen to think that this is a fantastic approach to software engineering. How nice would it be to know that when you start coding you don't have to do ANY interface design. Sure you have to build the views based on the prototype, but hey, you are no longer designing them, just implementing them. I look forward to trying this on small projects, so that I can prove to my company that this is a worth-while endeavour.
If you have a chance to catch any of Clark's presentations (I have seen several on usability and interface-design), you should check it out.
Looking For A New Job?
- Cold Fusion Developer/Designer at BPO Elks of the USA
- 10 year + CF lead Programmer/Developer with expert dot net/sql skills at Atprime Media Services
- ColdFusion Developer (advanced) at Intoria Internet Architects
- Full-time, remote CF Developer for Motorsport SaaS Company at MotorsportReg.com
- Contract ColdFusion Developer Needed at Kauffman & Associates, Inc.
This is actually what the Fusebox people have been evangelizing with the FLiP process for about 7 years. Glad to see others are recognizing the benefits as well, it is definitely a great approach!
While I don't know much about FuseBox, I do know that I listened to an MP3 about two years ago maybe of Hal Helms and Jeff Peters talking about the FLiP life cycle. This must have been about a year before Helms and Peters (Out Loud) was launched (and I think you can access this audio from that site). Anyway, that was my first introduction to the idea of up-front prototyping and the prototype freeze. I remember I copied it onto my iPod and was listening to it and got all Jazzed up and then went to work and try to sell my boss (at the time) about the idea.
It was kindly met with a "nice in theory, but that's not how the real world works". I look forward to proving that this CAN be the way the real world works on a project. Hopefully I can work on an internal project as a proof-of-concept.
Like Brian we've been using FLiP for years and always build the front-end first as a prototype. The client can then literally see if it's what they want. They will almost always see things they hadn't thought of and want changes, but that's ok because it's only HTML. When there are no more changes you know you've got an accurate picture of what the client wants you to build. And as you say your html views/css are already done.
It's important to explain the process to clients though. Occasionally you get someone who doesn't realise that you also need to develop the back-end and thinks they can start using the app straight away.