|
Speakers
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
|
|||||||||||||||||||
| 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. |