Schwartz starts by defining a test case. This is in essence a question; How can I future-proof my career? Once you know the question, you can then set about identifying key influences on your question–e.g. technological change–scenarios that may bring about the change–e.g. new competing technologies, lack of technological development in your sector, or the collapse of a key stakeholder–and finally, future implications.

Here is what Schwartz says in more detail:

1. List driving forces

What variables, trends and events will affect your mission? The first step is to list them. Next, divide them into uncertainties (such as economic, political and social conditions) and relative certainties (such as global population growth and climate change). Finally, rank the items according to their importance, from most to least significant. The result: a catalogue of factors that will determine the future of your area.

If I take web development as an example:

• Pace of technological change.
• Number of companies using the chosen technology.
• Number of people available in the industry (permanent and contract).
• State of the [digital] economy.
• Competing technologies, e.g. Ruby on Rails vs ColdFusion, AJAX vs Flash, offline vs online, desktop vs mobile.
• Support of the community, e.g. open-source software, tutorials and application servers.
• Support of key stakeholders, e.g. Adobe’s support of Flash, Flex and ColdFusion.

2. Make a scenario grid

Now it’s time to map out possible futures. The two most important uncertainties from the top of your list form the axes of the grid, with each of the quatdrants representing a potential future. Some may be more likely than others–and some may seem downright improbable–but they all depict the interplay of key forces. Thus, they’re within the range of possibility and deserve attention. They help you prepare for a range of possibilities and bolster core actions with those related to the future you deem most likely.

3. Imagine the possible futures

Sketched as a grid, these 4 possible scenarios are so abstract that it would be hard to recognise them if they merged. Make them more concrete by fleshing them out into imaginery, but plausible, news stories of the forces at play.

To continue the web development example:

• Global financial crisis prevents companies investing in technology. They cannot raise the adequate funding to push through key development projects, even if it means increasing efficiencies within the company.
• Adobe drops support for ColdFusion causing turmoil in the community. Railo picks up a lot of business, but can’t scale to fill the demand. Far-sighted companies migrate to other suitable platforms.
• Ruby on Rails booms under the paradigms: Convention over Configuration and Don’t Repeat Yourself, eating into ColdFusion’s key mantra: Rapid Application Development.
• Key advances in technology on the desktop and mobile continue at pace. Micro-payments allow people to create relatively cheap applications that appeal to a mass audience. Development frameworks allow developers to transfer their skills between technologies without the need for significant retraining.

4. Brainstorm implications and actions

Now it’s time to develop strategies for coping with each of the four possible futures you’ve imagined. Start by listing all the implications of each of the scenarios and then come up with actions that would enable you to prosper under any of the new conditions. Some actions would apply to almost any scenario: these should form the basis of your plan, since they help you to prepare for a range of possibilities. Bolster these core actions with those related to the future you deem most likely.

Examples of possible implications:

• Scarce funding.
• Limited demand for new technologies.
• Few companies to work for.
• Few new projects to work on.
• Increased competition for places.
• Increased demand for people with key skills, e.g. mobile.

and possible actions:

• Concentrate on existing technologies.
• Develop and exit strategy, e.g. cross-train into a new technology.
• Cultivate your network, make new contacts at major development houses.
• Polish skills in areas of uncertainty.
• Start your own cutting-edge business.

5. Track the indicators

The main value of the scenarios is that they sensitise you to the way the future is unfolding. Over time, the world is likely to gravitate toward one of your four quadrants. The trick is to recognise the shif in progress. As you monitor the news, look for signals that a particular possibility is becoming a concrete reality. Keep a file of news relevant to your scenarios, jotting down a quick note, along with the date, whenever you come across a significant story. Evaluate these developments on a quarterly basis so you can track the trends. Keep adjusting your action strategy to anticipate the future as it emerges.

Of course it is possible that none of your four quadrants becomes true. If this is so, you will need to go back and re-evaluate your scenario grid. Keeping a critical eye on your grid and apace of industry developments, you can be assured that the future will not change so quickly that you’ll miss an opportunity.

The 13 points made by Kevlin were:

• 0. Prefer code to comments.
• 1. Follow a consistent form.
• 2. Employ the contract metaphor.
• 3. Express independent ideas independently.
• 4. Encapsulate.
• 5. Parameterize from above.
• 6. Restrict mutability of state.
• 7. Favor symmetry over asymmetry.
• 8. Sharpen fuzzy logic.
• 9. Go with the flow.
• 10. Let code decide.
• 11. Omit needless code.
• 12. Unify duplicate code.

You can see a video of Kevlin’s presentation on the JAOO website.

Take this scenario. A company I once worked for had what can be described as a business directory built upon a licensed, yet bastardised, version of a popular ColdFusion-based CMS. It didn’t work that well! The decision was made to redevelop the application in Java. It took two years to reach the same level of functionality! What happened next? Ruby-on-Rails is what! The rest is history and beyond the topic of this post.

So, in effect, the application almost went full-circle in its development paradigm — both ColdFusion and Ruby-on-Rails can be considered Rapid Application Development environments, Java, certainly not. Why did the decision makers not stick with ColdFusion and put time aside to actually build it properly in the first place? To put it simply, they lost faith in ColdFusion; it was largely mis-understood.

The weakness of every programming language does not lie with the language itself per se — albeit it can have an important influencing factor — but rather with the ability, or indeed inability, of the developer to leverage the language in the most efficient and optimal way.

ColdFusion, like every other programming language has had and I’m sure still does have its fair share of poor developers; those people simply working with it as a means-to-an-end, rather than those passionate about the language, those people programming without understanding the fundamentals of programming or the implications of their poorly written code. This is apparent from .NET to Java, ColdFusion to Ruby, JavaScript to ActionScript.

Let’s not dilly-dally, bicker or insult one another about which is best, which one is dying and which one is not worth the computer it is compiled on. What is important is to understand the merits of each language and decide which one best suits the application, not only in technical terms, but also in terms of time-to-market, cost of development, availability of a skilled workforce etc.

ColdFusion, whether rightly or wrongly in some people’s opinion, can sit proudly amongst its peers and provide a truly compelling alternative.

Here’s how (in no particular order):

1. Low Total Cost of Ownership – frequently, ColdFusion is described as expensive, it simply isn’t especially if you consider the natively supported functions. But to put it bluntly, if your company cannot afford the cost of ColdFusion standard, or indeed ColdFusion hosting, you have bigger things to worry about regarding the profitability of the company; you won’t be able to afford much of anything! The problem becomes not the product. ColdFusion applications are quicker to develop and developers are vastly cheaper to employ than their peers in Java or Ruby, just look at ITJobsWatch for examples.
2. Rapid Application Development – ColdFusion vastly simplifies tasks. What would take other languages numerous lines of code to produce is efficiently encapsulated either in a tag or function or as a setting in the administrator. This is a simplistic yet indicative example: where else can you connected to a database simply with one line of code or indeed simply by name? ColdFusion changed the idea of specifying development time in terms of months and years to weeks and months or small features a matter of hours and days. Simplicity is not the mother or all evil. To be pragmatic, simplification reduces costs.
3. Rich Internet Applications – ColdFusion may or may not have pioneered the RIA paradigm, but it has played a significant supporting role to Flash and now Flex. ColdFusion natively supports Flash remoting, providing the all important data access tier.
4. Platform Maturity – ColdFusion 8 is built upon the latest version of Java (1.6). Along with internal improvements to the ColdFusion application, this has afforded ColdFusion unprecedented speed improvements and stability.
5. Language Maturity – with each major release of ColdFusion comes many language enhancements added to the core. This means that previous addons, for example image manipulation, which came at a premium are now standard. Adobe and other companies that produce CFML engines are now participating in a CFML advisory committee, which aims to set standards for the core language. This is not only a sign of maturity but a letter of intent by the industry that will mean your application will work on any engine, assuming no proprietary functionality is used.
6. The Ultimate Middleware – ColdFusion sits comfortably between any backend and front end system. Be it interfacing with a host of databases, Java, .NET, COM, Corba or connecting to classic HTML or rich Flash, Flex and AJAX frontends with little or no configuration.
7. Feature Rich – what other web technology natively supports PDF generation, charting, enterprise-level search, AJAX, image manipulation, Atom and RSS creation, Zip and JAR file manipulation, a server monitor, Flex integration, encryption libraries, all important database connectors, webservice creation, XML manipulation, inbuilt reporting application (similar to Crystal Reports), email, FTP to name but a few? I hazard a guess at none, unless you’re happy to pay a premium.
8. Platform Independent – since ColdFusion 6, when Macromedia redeveloped the entire application in Java, ColdFusion has been platform independent. You can install it on practically any machine.
9. OpenSource Alternatives – BlueDragon and Railo are both significant alternatives to Adobe ColdFusion and both have opensource alternatives, the latter of the two having recently joined the JBoss community. Adobe are also considering providing a free edition to academic institutions.
10. The Future – many commentators have mentioned Hibernate as a significant addition to the next release of ColdFusion, version 9. But having seen the prerelease notes, that is not all that will be added. Alas I’m under NDA, but rest assured, there is going to be a significant intake of breath when developers get hold of the next release. ColdFusion 8 was firmly geared towards middle management with fuzzy additions, ColdFusion 9 is set to re-address the balance with compelling language and functionality enhancements.

ColdFusion evangelism needs to step up a gear! Adobe certainly doesn’t afford much marketing budget to the product, prefering The Community do the hard work. It is not always easy convincing the decision makers that ColdFusion is a good product of choice, without Adobe’s unnerving support, but we have to work hard, break down those barriers, encroach on events outside the comfortable sphere of the ColdFusion world and demonstrate ColdFusion’s match-winning ability.

ColdFusion isn’t dying, it’s simply niche. Every niche has its place.

UPDATE: If you would like to view the ensuing debate regarding ColdFusion prompted by Aral Balkan, feel free to do so. This post should serve as a positive reminder of ColdFusion’s virtues, alongside the need for a balanced and polite debate.

With the increasing importance of Rapid Application Development (RAD) and the popularity of the Ruby language driven by Ruby on Rails, this user group aims to assist developers in defining their role, provide information resources and a chance to meet fellow developers and provide a centralised network within the community.

To join the group and start networking, simply click on the link below:

UK Ruby User Group:

http://www.linkedin.com/e/gis/31026/79705D6CDE7C

Frameworks can help promote good development practices, standards, and a sound foundation for creating an application.

In this article I list a number of these frameworks, but I will leave you to compare them, and decide which you may want to adopt.

Fusebox

An Historically Strong Framework

Fusebox is a popular framework for building ColdFusion and PHP web applications. “Fuseboxers” find that the framework releases them from much of the drudgery of writing applications and enables them to focus their efforts on creating great, customer-focused software.

Fusebox provides a small set of ‘core’ files and large amount of structure which is helpful to developers. It emphasizes separation of presentation from logic and uses a readily understandable vocabulary for modeling websites, namely circuits, fuses and switches.

http://www.fusebox.org

Mach-II

Mach II is a web-application framework developed by Hal Helms and Ben Edwards that evolved out of a desire to create a framework that specifically addressed maintenance issues using an OO style. Mach II is based on an Implicit Invocation Architecture and directly supports the MVC design pattern.

http://www.mach-ii.com

Model-Glue

Model-Glue helps you build Object-Oriented ColdFusion applications based on the Model View Controller pattern. It’s designed to be easy to use and play well with others, like Tartan.

http://www.model-glue.com

onTap

The onTap framework is an Open Source Framework for quickly developing powerful web applications using Adobe’s ColdFusion application server. The framework itself bears a marked resemblance to the recently buzzy Ruby on Rails.

http://www.fusiontap.com

TheHUB

TheHUB, like other application development frameworks, utilizes the notion of a central hub template that all requests for the application pass through. That cental hub is the point or place within the application that the processing of all code hinges upon. The code simply checks for a query string and then reads the parameters passed to handle template loading and screen rendering.

http://www.codesweeper.com

Tartan

Tartan is a command-driven service framework for ColdFusion. It was built to help produce the service layer within a larger application architecture which relies on strict separation or layering of functionality.

All access to the underlying business logic is controlled by public services which are available locally as CFCs and remotly via Flash Remoting and SOAP web services. A service can be composed of any number of commands, each of which implements a discreet operation within the application. These contain the core logic for the application. Commands can communicate with databases via DAOs, manipulate values received from the client, execute other commands and even communicate with services available on other remote servers.

At the center of Tartan are 6 Core classes : LocalServiceProxy, LocalService, Command, DAO, ValueObject and ExceptionHandler. They provide most of the functionality of the framework, and must be extended by the application developer.

http://www.tartanframework.org

ColdSpring

ColdSpring is a framework for CFCs (ColdFusion Components).

ColdSpring’s core focus is to make the configuration and dependencies of your CFCs easier to manage. ColdSpring uses the “inversion-of-control” pattern to “wire” your CFCs together. Inversion-of-control provides many advantages over traditional approaches to assembling your application’s model. Also part of ColdSpring is the first Aspect-Oriented-Programming (AOP) framework for CFCs.

http://www.coldspringframework.org

UPDATE: Since creating this blog post many years ago, two more frameworks have been released that require an honourable mention.

ColdBox

My New Framework of Choice

ColdBox is an event-driven conventions based ColdFusion Framework. It provides you with a set of reusable code and tools that you can use to increase your productivity, and it provides you with a development standard when working in a team environment. It makes use of an MVC (Model View Controller) design pattern and an extensive array of patterns for its operations such as Factories, Helpers, Workers, etc. And since it is based on CFCs it does not rely on an XML dialect.

NB. ColdBox also takes advantage of ColdSpring or Lightwire.

http://www.coldboxframework.com

Lightwire

Lightwire is a very lightweight Direct Injection (DI)/Inversion of Control (IoC) engine for directly injecting dependencies into singletons and transient business object. The framework is optimised to create transient objects as well as singletons and allows for programmatic as well as XML configuration. It is the lightweight framework for people who’d like to put more logic in their beans and less in their service layer.

http://lightwire.riaforge.org

The onTap Framework can be downloaded at the following url:

http://www.fergusonhouse.com/?netaction=download