CFUN-04 Homepage
Central Location of ColdFusion Conference and Seminars
Spread The Word
Register Exhibitor Information Survey News Faq's blog Share cfun-04 photos

Professional Web Tools

More Sponsors:

   Charlie Arehart
   Jo Belyea-Doerrman
   Tim Buntel
   Raymond Camden
   Christian Cantrell
   Sandra Clark
   Joey Coleman
   Sean Corfield
   Robert Diamond
   Michael Dinowitz
   Steve Drucker
   David Epler
   Joseph Flanigan
   April Fleming
   Ben Forta
   Shlomy Gantz
   Mark Gorkin
   John Hamman
   Hal Helms
   Simon Horwith
   Larry Hull
   Jeff Houser
   Chafic Kazoun
   Matt Liotta
   Tom Muck
   Rey Muradaz
   Nate Nelson
   Samuel Neff
   Jeff Peters
   Bogdan Ripa
   Neil Ross
   Margarita Rozenfeld
   Stephen Shapiro
   Michael Smith
   Geoff Snowman
   Jeff Tapper
   Dave Watts


Ben Forta

Colder Fusion - Twin Cities ColdFusion User Group
SacCFUG - Sacramento, California ColdFusion Users Group
MMUG-Dublin UserGroup Meeting
1  |  2  |  3  | 4  | 5  | 6  | 7  | 8  | 9 | 10  | 11  | 12  | 13  | 14  | 15  | 16  | 17  | 18  | 19  | 20  | 21  | 22  | 23  | 24  | 25  | 26  |  27  | 28  | 29  | 30  | 31  | 32  | 33  | 34  | 35  | 36  | 37  | 38  | 39  | 40  | 41  | 42  | 43  | 44  | 45

Back To Interview list

Michael Smith: I am talking with Neil Ross about "Application Blueprinting,", a talk he is giving at CFUN-04. Why should programmers care about blueprinting their applications?

Neil Ross: To be quite honest, Michael, developers generally don't think much about the real value of application blueprinting, better known as DOCUMENTATION, until they are lost without it. I've long held the belief that before a developer starts to hammer out any code they should understand the customer's needs well enough to articulate it on paper. Creating and maintaining a record of the customer's requirements and the needed application processes is not really the fun work, but should be viewed as being as important as the application code itself.

MS: So what can happen when blueprinting is not done on a project?

NR: What people don't seem to realize is that whether you actually plan things out or not... whether you really plan a solid application architecture, you'll still have an architecture. The real disadvantage is in the fact that you don't have any formal plan or blueprint to refer back to or to plan your next steps on top of.

MS: So that leads to maintenance headaches...

NR: You're right, it does. Not only do you have headaches with maintenance of the existing application, but extending the application with additional functionality becomes more and more of a challenge.

MS: Is this the famous spaghetti code?

NR: The purpose of having the well-defined architecture is really to eliminate the chance for the occurrence of "spaghetti code" and to help find your way out if you find that you've arrived at "spaghetti code" unexpectedly. A good architectural blueprint ensures that you get the most clear picture of how the application code should work together. It can be used to help pinpoint sections of code that would be good candidates for encapsulation into reusable custom tags, user-defined functions or ColdFusion components.

MS: Does that affect how buggy the code is?

NR: Well, I'd like to say that having a good application blueprint or architectural documentation eliminates buggy code, but these documents are only maps. As with any map, if you don't follow the directions that it gives you, you could get lost. Developers have to learn to follow the plan and commit to keeping the blueprint up to date so that gaps don't appear between the documentation and the true functionality of the application.

MS: Right. In some areas of the country they are building roads so fast that the maps are out of date and it is easy to get lost in my car! I guess code is the same way, except getting lost leads to bugs. Is there any software to make the mapmaking and updating easier?

NR: Right indeed, Michael. There is in fact some software that I'll be using during my session to show attendees just how easy it can be to map out their applications by creating process diagrams, to maintain a requirements list and associations of those requirements to application elements, and even to import data elements into their documentation. This software is called Adalon. It is from Synthis Corporation and I've been using it for a couple of years now to do technical documentation for the applications that I build.

MS: Wow that is cool - I will look forward to seeing your session.

| Home | Topics | Speakers | Directions | Spread the Word | Register |
© Copyright TeraTech Inc 2003
405 East Gude Drive Ste 207 Rockville MD 20850
301.424.3903  Fax 301.762.8185
Please send comments/questions to [email protected]
For sponsorships or registration, please send comments/questions to liz-cfun04 (at)