Subscribe Now

A New Vision for ColdFusion

By Hal Helms

The following article will be published in the Winter 2007 issue of the Fusion Authority Quarterly Update.

In a recent conversation, a friend and I were discussing the features that we'd like to see in ColdFusion 8. My friend said that he'd like to see new features for CFCs – things like constructors, interfaces, and static methods, things that are common in several object-oriented languages, including Java and C#. My friend's thoughts mirror what several bloggers have wished for. Some time ago, I would have agreed with this developer, but I've had a change of heart. Why the change in my position? I'd like to share with you some thoughts on the topic. Much that follows is taken from a talk I gave at cf.Objective(). It lays the groundwork for a vision for ColdFusion that concludes this article.

Marketers speak of the importance of product positioning. The concept of positioning gained wide acceptance some twenty-five years ago in the book, Positioning: The Battle for Your Mind. That book, by Al Ries and Jack Trout, rocked the business world. Ries' and Trout's thesis is that prospective buyers of a product – and that product can be popcorn, programming languages, or presidents – identify brands by a single word or concept. In your prospect's mind, that word is your product's position. According to Ries and Trout, people are so overloaded with information and product claims that marketing messages are distilled down to a single word or, at most, a short phrase.

Let's see if we can identify some commonly held positions for a few well-known brands. See what concept each of these brands occupies in your mind: Volvo, Ritz-Carlton, Haliburton. For most of us, Volvo conjures an image of safety; Ritz-Carlton, an image of luxury; and Haliburton, an image of corporate greed. Once established within a prospect's mind, a brand's position is remarkably stable. Marketers who understand the power of positioning are very careful to avoid counter-positioning – sending a message that differs from the brand's established position. Years ago, Porsche decided to extend their brand by producing a reasonably priced car, the Porsche 914. The product was a failure. Why? To most people, a Porsche is a fast, sexy, and expensive car. The 914 was pure counter-positioning. Line extension, the strategy employed by Porsche, is very popular among business executives. After all, they reason, why not leverage the strength of our brand and appeal to a different market segment-people who would like a Porsche and want to associate themselves with that position, but can't afford the brand's pricier offerings?

At best, the market ignores counter-positioning claims. This was the case with Porsche-very few people bought the car. At worst, though, a counter-positioning message confuses people and dilutes the strength of the brand itself. Chevrolet, at one time, held the position of a modestly priced commuter car. But through line extension – everything from the Nova to the Corvette – Chevrolet has undermined that position. What position does it hold now? As Chevrolet's dwindling sales show, it has no strong position in prospects' minds.

Toyota is one example of a brand that understands the power of positioning. When the company wanted to appeal to a different market segment – people who wanted a luxury car – they established Lexus, an entirely new brand that could lay claim to the luxury car position. The strategy was highly successful: Toyota is a reliable mid-priced car. Lexus is an expensive luxury car.

Let's move from the world of cars to one closer to us. What positions do these computer languages hold in the minds of IT executives? Java, COBOL, LISP. For most, Java means enterprise; COBOL means legacy; and LISP means esoteric. (We can see from COBOL that positions can change over time. COBOL was not always viewed so negatively, but times change and – sometimes – peoples' perceptions change with the times.)

Now, while you're still inside those executive's heads – and while you're marveling at just how much space there is in there – I want you to think about how those managers would answer this question: What is ColdFusion's position? What one word describes it – not from your point of view, but from theirs?

I've asked this question to several executives. Among words like easy and simple, perhaps the most-commonly used term is light-weight. And this is a positioning problem. In the world of IT, light-weight is a pejorative term. For IT managers – CIOs, and CTOs, who are very susceptible to herd mentality – Java and C# hold the positions of being industrial-strength, enterprise-grade languages. ColdFusion, alas, does not.

We've all heard – and been annoyed by – the raps against ColdFusion: it's not secure, it's not scalable, and so on. And we know that's simply not true. So it might seem that we should concentrate our efforts on showing that ColdFusion is perfectly capable of taking on enterprise-mission applications, which we know it to be.

Anyone who's heard the familiar arguments that ColdFusion is Java or ColdFusion is the fastest way to build Java applications will recognize these arguments as attempts to set the record straight. Arguments like ColdFusion is Java are logical arguments, but positions are held on a deeper, gut-instinct level and once held, are deeply persistent. It's not that the argument fails; rather, it is ignored.

Napoleon, the great general, was once asked Sir, whose side do you think God is on? His reply is just as applicable for positioning as it is for warfare. He said, I have observed that God is most often on the side with the biggest battalions. Apparently, Napoleon is right. In one study by Ries and Trout, twenty-five different categories of products were examined to see which brands were leaders. The study then looked at the same categories sixty years later. Twenty of those 25 brands still held the number one position.

So, my question is this: How do we win this battle for people's minds as it pertains to ColdFusion? But perhaps we should ask another question: Why do we care about the fate of ColdFusion? After all, we learned ColdFusion and we can learn another language. Why bother engaging in battle at all? I believe we should care for the same reason that Apple users are so fanatic about their machines and their OS and refuse to capitulate to Windows. It's the same reason that Firefox developers were too foolish to realize that they had no chance against the enormous resources Microsoft committed to IE.

In both of these cases, the side with the smaller battalions was fueled by a powerful idea: that they were right. Many of us do know multiple languages, yet we continue to prefer ColdFusion. And while I believe that we are right – that ColdFusion has a vital role to play in the enterprise – we must be strategic in the way we approach the IT executives who make decisions about which languages will be used.

Let me give you an example of one way to approach your CIO. It's done in the form of an email.

And then I proceed to offer a reading list to our CIO to back up my position. Good move, no? No. If anything is more certain than death and taxes, it's this: people don't change their minds when told they're wrong. What do they do? They dig in. And then the side with the bigger battalions does win. But if people are unwilling to admit that a decision they have previously made was wrong, they just may be able to make a new decision. And to assist in this, we need new strategy.

In the battle for minds, smaller competitors often go for the frontal attack. Its virtues: straightforwardness and simplicity. Its weakness: it seldom works.

Some years ago, RC Cola made a concerted effort to take on Coke and Pepsi. The CEO rallied the troops with a speech in which he said, RC is, in every way, as good as Coke or Pepsi. But our product – every bit as good – is cheaper! While this played well among the loyal RCers, it fared rather less well among the general public. This is the normal outcome when attacks are launched against a perceived weakness on the part of a leader. After all, when was the last time you bought an RC cola?

Attacks against perceived weaknesses typically fail. Attacking a leader's strength, on the other hand, may just afford a real possibility for prospects to make new decisions. In the 70's, Avis was a distant second to the market leader, Hertz. Avis didn't choose to say, We're better than Hertz. They knew that saying such a thing was tantamount to telling prospects, You were wrong in your decision to think of Hertz as the leader. People don't like to be told they're wrong, and when told, they seldom change their minds.

Instead, Avis came up with a brilliant campaign, advertising themselves as not the leader. We're No. 2, Avis advertised. In one ad, Avis offered prospects this to consider: Rent from Avis. The line at our counter is shorter. They didn't attack the leader's weakness. They attacked the leader's strength. We're just as good as Hertz – and cheaper would have been a me too attack on perceived weakness.

The brilliance of the campaign was that the very nature of Hertz's strength – of being the market leader – was susceptible to attack. And Avis' results were as different from RC Cola's as was its strategic attack. While I can't remember the last time I had an RC Cola, over the years since their campaign, I've rented quite a few cars-and a good number of those have been from Avis.

But what does all this have to do with ColdFusion? Who are the Coke and Pepsi of enterprise development languages? Java and C#. The ColdFusion is Java argument is a me too strategy that lacks the power to help prospects make a new decision. What, though, if we attack-not Java and .NET's weakness-but their strength? What are the strengths of the J2EE and .NET platforms? They are perceived as secure, robust, and enterprise-capable. To use an analogy, these languages are to applications what steel I-beams and concrete are to buildings.

Certainly, if you want to build a true enterprise-class application-something that can scale to thousands of users, something that is mission-critical – it's pretty hard to argue with J2EE as a choice. But the decision doesn't end there. The philosopher and physicist, Eli Goldratt, has developed a system of thinking he refers to as the Theory of Constraints (or TOC). Goldratt stresses what he refers to as system thinking and his work was greatly influenced by the work of Edwards Deming, the man famous for teaching quality to the Japanese.

TOC states that within any system, there is one, and only one, constraint operating at any point. The mission of the manager is to lift that sole constraint on the system. Let's apply TOC to the case of enterprise development. What is the constraint in the system? We know that a great deal of enterprise software is deemed by the only jury that counts-the users of that system-to be a failure. But why? What is the failure point? If the failure point is an inability to scale, or a lack of security, or is simply not robust enough, then J2EE and .NET may well be the answer and all the ColdFusion IS Java talk in the world will fall on deaf ears.

But are any of these the constraint on enterprise software development? Ask users why a recent software implementation goes unused and they'll likely tell you this: the application doesn't do what we need it to do. This is the failure point. Users aren't getting what they need. How bad is the problem? Dr. Ralph Young of Northrup Grumman Information Technology division estimates that 85% of defects in developed software originate in failed requirements.

How do we discover user requirements? For years, I've been preaching the virtues of designing the user interface first-before the database schema, before the application modules, before the domain model. The reason is simple: to the user, the interface is the application. Alan Cooper, the father of Visual Basic, has written two books that count the user experience as the most important aspect of software. Jason Fried, the CEO of 37 Signals, the company behind BaseCamp and Ruby on Rails, recently said in an interview: We do things a little differently: we design the user interface first.

The reason for the user interface first movement is simple: traditional methods of discovering user requirements just don't work. We've all sat through meetings, conducted user interviews, passed out requirements questionnaires. Or maybe we're lucky enough to have a thick requirements document handed to us. Incontrovertible evidence compels us to recognize that such techniques fail at uncovering what users really want.

Concentrating on the user experience, on the other hand, fosters innovation-as those of us who practice the technique know. Innovation occurs when a system is in place that allows for rapid response to user requirements, where applications are flexible enough to meet unanticipated-and unanticipatable-demands of users in the real world, where versions can be rolled out rapidly by a system agile enough to provide for quick responses.

It's a world in which lightweight is a key to innovation and perhaps, ultimately, to survival. It's a world perfectly suited to a language such as ColdFusion.

I used the analogy of concrete and steel earlier when talking about J2EE and .NET. Their problem is not their weakness, but their strength. If you know exactly what you are going to build and that system is going to remain stable (i.e., there will be no innovation), then Java or C# are great choices. But if the constraint on the system is the lack of ability to innovate, to (a) discover requirements and (b) respond rapidly to changing customer needs and requirements, then applying J2EE or .NET to the user interface may just make the situation worse. Their strength is their weakness.

Let me give you an example of how this can work in the real world. A corporation I worked with was struggling with the idea of standardizing on J2EE for all application development. The problem was that most of the applications that they used on a daily basis were written in ColdFusion. They knew by experience that the Java team took much longer to deliver a similar application and that the application was more expensive to develop. Further, it was harder to change. And yet, they wanted to standardize on a single way to do certain things.

My recommendation to them was that they continue fostering innovation with ColdFusion, yet roll up those standardized aspects into Java components, once it was clear exactly what those components should do. An MVC framework such as Fusebox, Mach-II, or Model-Glue made it a simple matter to swap out the domain model ColdFusion components for domain model Java components if, and when, it made sense to do so.

For 18 months, the company has followed this plan and reports great success doing so. A side benefit is that both their ColdFusion and Java developers are happier in their respective roles. Discovery and innovation happen within ColdFusion. Standardization and consensus occur within Java. And both work well together.

A remarkable opportunity exists for propelling ColdFusion into the enterprise. After languishing for years following the dot com boom, the Web is suddenly hot again. Web 2.0 – whatever that term may actually mean – has caught the attention of the broader business market. And we stand to benefit: demand for web programmers is outstripping the supply. Programmer salaries are rising. The old adage applies: a rising tide lifts all boats. But what of ColdFusion specifically? What part will it play in the resurgence of the Web? How can it best leverage these trends? Some ColdFusion programmers want ColdFusion to compete head-on with Java and C#. Give us interfaces. Give us abstract classes. Give us constructors. Make ColdFusion more like Java. It's the RC Cola strategy all over again.

But what if ColdFusion were, instead, to focus all its efforts on empowering programmers to create fantastic user interfaces quickly and easily? This has always been a strength for ColdFusion. What if, to borrow an analogy from the Extreme Programming camp, the dial was turned to 11? What would this look like? What would ColdFusion 8 offer? If this strategy were adopted, we would likely see integration of Flex components with ColdFusion tags and functions. ColdFusion would offer the ability to use Ajax seamlessly. Flash widgets could easily be added to interfaces.

There's a temptation to want it all-to have a language that offers great user interface capabilities and all the server-side features of Java or C#. It's the classic appeal of line extension, a strategy that repeatedly, predictably fails. Are we really willing to believe that this time it will be different? I am not. I hope that Adobe will recognize the unique strengths of ColdFusion and augment these to lift the great constraint facing developers-the difficulty of understanding and quickly supplying the needs of users.

If the bloggers who want ColdFusion to be more like Java have their way, ColdFusion will just be another general-purpose language. Wanting to have it all is a fantasy. In the real world, defining what a brand is also means defining what a brand is not. Every R&D dollar that goes into making ColdFusion more like Java is a dollar that is not available for making ColdFusion the best choice for creating great user interfaces. We've seen what happens when a brand like Chevrolet tries to offer it all: they fail. Let's encourage Adobe to focus all their efforts on positioning ColdFusion as the language of innovation.

---

Hal Helms writes, speaks, and consults on software development. His podcasts with Jeff Peters can be downloaded from http://helmsandpeters.com. His popular "Occasional Newsletter" is available at http://halhelms.com. Hal can be reached at hal@halhelms.com.

del.icio.us | digg | Spurl | Simpy | Newsvine | BlinkList | Furl | reddit | BlogMarks | Yahoo! My Web | Ma.gnolia | Technorati

• Subscribe
• RSS

• Editorial
• Specials
• Community
• News
• Tech and Tags
• Views
• Reviews
• Techniques
• Security
• Best of ColdFusion Talk
• Knowledge Base
• Blog Watch

• Tipical Charlie

Quarterly Update