The Largest Repository of ColdFusion Knowledge in The World for More Than 12 Years

ColdFusion on Ulitzer

Subscribe to ColdFusion on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get ColdFusion on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


CFDJ Authors: AppDynamics Blog, Michael Kopp, Tad Anderson, Bob Gourley, Jayaram Krishnaswamy

Related Topics: ColdFusion on Ulitzer, Java EE Journal, Java Developer Magazine

CFDJ: Article

What Really Leads to Successful Software?

What Really Leads to Successful Software?

ColdFusion MX is a complete, from-the-ground-up rewrite of an existing piece of software, shifting its architectural base from a purely interpreted language sitting atop C, its base language, to one that compiles into Java code. That's quite a shift.

For months Macromedia has been reassuring developers that, whatever may happen beneath the covers, nothing changes about our code. In one sense that's absolutely true. Take code written under a previous version of ColdFusion and - almost without fail - it will run perfectly with ColdFusion MX. In that sense "nothing changes" is an accurate reflection of reality.

On another level "everything changes" is an equally valid description of the new world that CFMX has led us into. ColdFusion's new foundation of Java offers us new capabilities, such as using JSP custom tags in ColdFusion pages. Charlie Arehart (www.systemanage.com) has been very helpful in pointing out in his articles and seminars new ways of utilizing the CF-Java connection.

Certainly ColdFusion's native XML parsing will open up new opportunities for us, and the use of CFCs promises to make coding simpler, easier, and more robust - a nice trifecta.

I've talked with many developers who sense that everything does indeed change with ColdFusion MX, but can't fully articulate what those changes might be. Often this conviction is accompanied by a certain dread, a fear that the good old days of coding in ColdFusion may be over, that the door of opportunity that ColdFusion represented is rapidly closing, to be replaced by a guarded and armored door with a sign reading, "Dare not enter save ye have a propeller on thy head." Or words to that effect.

This would be a tragedy, as the bad old days of the propeller heads in charge are little missed. (See Alan Cooper's wonderful The Inmates Are Running the Asylum for a brilliant perspective from a truly qualified propeller head.) Still, I do think that ColdFusion MX will bring in changes that we don't fully apprehend.

We've all heard the probably apocryphal curse, "May you live in interesting times," and the post-MX world may prove very interesting. But we may take heart in another old saw that tells us that every danger is also an opportunity. That's what I'd like us to consider in this article.

In my training classes (www.halhelms.com) I use a wonderful quote by MIT professor Hal Abelson: "If we can dispel the delusion that learning about computers should be an activity of fiddling with array indexes and worrying whether x is an integer or a real number, we can begin to focus on programming as a source of ideas."

Many people, too long kept at bay by the old-style propeller-head guards, will readily agree with the first part of this statement. They love the fact that ColdFusion doesn't obsess over variable types and appreciate that sanity is restored by, for example, beginning to count arrays at one instead of zero. But Abelson doesn't stop with a mere indictment of excessive fussiness; he adjures us to view programming as a source of ideas - and there's the rub, to borrow a phrase from another author.

After we get over the delusion that programming is about twiddling bits, we're still left with the much harder matter of ideas - of thinking clearly - and that's no small matter.

I recently spent several hours with a company that wanted me to consult with them on building a large Fusebox application. This was an introductory meeting in which they were to sketch the outline of the project and fill in the details on what had been done to date. My job was to absorb information and lay out a plan for going forward.

After initial introductions, they referred me to two giant whiteboards that looked truly impressive. They were covered with words and symbols, and atop each board, in bold letters, were the words DO NOT ERASE!!! They began to ask me questions about nesting circuits, how to reuse fuseactions, and how nested layouts should be handled using Fusebox.

Now these are excellent questions, but something was lacking. Our discussion was highly abstract and theoretical, necessitating virtually every statement to be modified with the unhelpful phrase, "Depending on the application...."

I became concerned that there was no concrete thing we could talk about. Even though I spend a good deal of time theorizing, I'm very cognizant that what matters are real applications with real deadlines and real budgets. If theory doesn't help developers successfully deploy projects on time and on budget (or preferably below both), it's no more than mental gymnastics.

"Have you gone through a prototype, and if so can I see it?" I asked.

The room grew rather quiet. They hadn't gone through a prototype, or rather, they had a few pages mocked up and felt that was going far enough. "We don't have a full prototype, if that's what you mean," I was told.

"How do you know what you're building?" I asked. I was told that the whiteboards represented the "architecture" of the application. I saw various menus and a few logical groupings but nothing I'd call architecture.

"We know it's not complete," they said. "That's why we want your help - to design a good architecture."

I tried an illustration: "With a physical building, the choice of an architecture depends on a number of factors, including items highly important to clients (shape, size, colors, etc.) and those underlying issues that a good architect is responsible for understanding, such as structural engineering, electrical, plumbing, and so on. Until the architect knows what the building will look like, issues such as the stress on load-bearing beams simply can't be determined. It's really the same with a software 'building.' That's why I really urge you to begin with a prototype: it will reveal issues and questions that aren't obvious in the abstract - issues, in fact, that will make or break your project."

It was no good; I wasn't convincing them at all. The more we talked, the more it became clear to me that what they wanted from me was an all-purpose architecture that would fit a wide variety of projects and would be adaptable to the changes that are inevitable in a software project. I finally had to say that I was very sorry, but wouldn't be able to help them with the project. I wished them the best and we parted.

My purpose in relating this is not to denigrate these folks. I have every reason to believe that they are hard-working, conscientious, and passionate about creating successful software. But they lacked knowledge of what leads to successful software, and assumed, in the absence of knowledge, that they could hire someone to produce an all-purpose architecture. And that, neither I, nor anyone I know, can do.

If this were an aberration I wouldn't mention it, but I've become convinced that it's all too often the rule rather than the exception. We developers want to "get coding." Or at least get the database design out of the way. Do something real. Something concrete. We aren't treating programming "as a source of ideas," but are back to throwing code against the wall to see what sticks.

The irony is that all this "concrete" work has no firm basis, no real architectural foundation. And without that foundation the structure being built will almost certainly fall.

I seem to have gone far afield from my initial sentences about the conjunction of Java and ColdFusion, but I see a strong connection between my first thoughts and this tangent about a client. I agree that ColdFusion's close relations with Java will change a great deal about how we do things, and I want to see that change benefiting us developers and our clients.

For that to happen we must examine the idea of software architecture; we must make sure that we think first and program after our thoughts are clear. This is neither easy nor fun, at least not initially. Developing a software architecture sometimes to involve nothing so much as finding ourselves along conceptual dead-ends that seemed promising when the path first appeared.

When we speak of "thinking clearly," what we mean is the courage and fortitude to toss out our ideas, to "go back to the drawing board" - literally in our case. Throwing out hours or days of plans isn't enjoyable, no matter how positive our outlook. It feels like a loss, and indeed it is. We persevere because we've found that undergoing some pain initially gives us a much, much greater chance for success later on.

*  *  *

Next month I'll write about a software architecture called Model View Controller, or MVC. MVC was initially created by the bright lights at Xerox Palo Alto Research Center (PARC), and has been used for many complex, sophisticated applications. An adapted version of it forms the recommended Model 2 of the J2EE architecture. In my classes I teach MVC as well suited to certain types of applications and show how it can be used with Fusebox. I have to warn you that parts of MVC aren't intuitive - again, at least not initially. The advantages of mastering this architectural model, though, are significant and can help ensure that our projects don't fail for lack of a robust foundation on which to stand. So eat your Wheaties, and I'll see you next month!

More Stories By Hal Helms

Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.