Devil Went Down to Silicon Valley

Adrian Moreno posted this tutorial for converting an existing application to use Mach-II in a thread on the cf-talk mailing list earlier today. There was also some talk of people converting from ASP.NET to ColdFusion or vice versa (accompanied by the usual chatter over the "imminent death" of ColdFusion due to developer attrition, etc). Someone else had also mentioned PLUM and having been surprised that it hadn't been better received in the ColdFusion community. It got me thinking about something that I'd actually been thinking for a while, that often times I think new approaches / methods in the ColdFusion community (perhaps any development community) end up being not well received or getting very little recognition not because they're "bad" but simply because they have a different philosophy and people either have a difficult time wrapping their heads around the alternative approach or are just disinterested simply because it's different.

If you look at this poll I found from the cfframeworks.com website. I'm attaching the CSV from the time of this article, which you can download below. Now although this is a very crude examination, you can't really ball up FuseBox here for my purposes because it had a lot of traction already from years of implementation before most of these frameworks were even a twinkle in someone's eye. However if you compare the remaining frameworks, it seems that pretty consistently, the frameworks with both the highest scores and the largest number of votes are those with the most traditional (from a Java perspective), OO-style approach.

Style is a very important word in this sentence, because while I've yet to write any application with anything less than a 100% OO model layer since I first implemented support for CFCs in the onTap framework, I have yet to see anyone else write an article that mentioned the onTap framework without explicitly stating "it's not OO", which I believe stems largely from the lack of XML config files, which have absolutely zero to do with OOP. They are however a good part of the traditional style of OO programming in the Java community. It's unfortunate because I think that's discouraged a lot of people from trying the onTap framework, thinking "oh it's procedural, why bother".

The overal emphasis however seems pretty consistent. More people try and stick with frameworks that use the more traditional Java/OO-style approach in today's ColdFusion community than experiment with frameworks that take an alternative approach. The bulk of people voting have at least tried and many "stuck with" Mach-II, Model-Glue, ColdSpring, Reactor and to a slightly lesser extent FarCry and Transfer. Frameworks that approach things a bit differently such as onTap, PLUM, CFonRails, COAL, ObjectBreeze and LiteWire comparatively have similarly small numbers of votes and low general rankings. Which to me seems odd given that the same community gives a higher ranking in the survey for using no framework at all!

It also reminded me of a comment that Sean Corfield had made on Kola Oyedeji's blog the other day. He said:

When we use 'DAO' and 'Gateway' in the ColdFusion world, we are a lot closer to the "Row Data Gateway" and "Finder Class" position. I'm not quite sure where our current usage originated but one of the problems we seem to face as a community is that when an example is held out to illustrate an approach, many CFers take it as _the_ way to solve that problem.

Though this isn't just a plea for the one I maintain either, I think more people should try PLUM and COAL also and I know much of the time I don't have much room to talk. I've fallen pray as much as the next guy to not working this experimentation into my schedule. It was a long time before I examined Reactor.

In the process of searching google to find the above quotable Corfield (boy was that a challenge), I also came across this blog from Sean on the subject where he references Kola's article (which references Brian Rindaldi's) as well as one from Matt Woodward. It's a lot of talk about a subject I'd been meaning to talk about in this blog recently but hadn't gotten around to writing. The contention and the frustration between wanting to have good clean use of design patterns and knowing how often people turn them into Golden Hammers, the problem that leads some people argue that design patterns are bad (for software design).

I've also heard Sean make the comment (in person at cf.Objective in 2006) that good programmers should exit their comfort zone regularly and work with concepts which are new to them and alter their method of thinking about the process of programming. This is in itself contrary to what our employers often insist, that we use "proven methods" in everything we do... it is however, in keeping with the spirit of innovation, after all, in any environment that takes R&D seriously, there is an expected 80% failure rate.

I think it's a good thing for us to consider why it is that these companies that take R&D seriously (pharmaceutical is a good example), expect 80% of their projects to fail and become concerned if the failure rate drops. When considering the answer to this question, one must also consider the outsider effect.

The people who introduce basic innovations are frequently from a different industry or discipline than the one in which the innovation occurred. For example, Sir Henry Bessemer, the man whose discoveries transformed the steel industry, was involved in glass and paints. The innovation of the theory of DNA that created the new discipline of microbiology and the biotech industry was due to a team consisting of two physicists, a chemist, and one biologist. New Zealand inventions are no exception to this rule examples being the Hamilton Jet Boat, the Gallagher Electric Fence, the Navman GPS Marine Product, all of which were created by people working outside of their area of "specialisation".

...

At the same time, certain cities, industries or monopoly suppliers can become set in their ways and resist new industries or technologies, particularly those that challenge existing paradigms.

The latter part of this quote is also something described by Machiavelli in his book the Prince. So it's not particularly new - it's just not popular to mention it. I might add for the record that psychology has been revolutionized by the linguist Chomsky in an event that sparked the creation of what we now call cognitive sciences. There also used to be a better article about the outsider effect on the web, but it seems to have been taken down. In the other article the author described specifically how Bessemer had revolutionized the steel industry and he pointed out that it was achieved via a technique that would have, had he been a steel worker, got him FIRED without question from every company in the industry during his day.

What revolutionized steel was an indefensible, cardinal sin! He blew air at molten steel. And contrary to the popular belief that it would make the steel less pliant and harder to work with, it turns out that it reacts (with oxygen I believe) to make the steel more pliant and easier to work with. It has precisely the opposite of the expected effect. The important thing to note here is that because the steel industry had that specific expectation, it was literally impossible for anyone working within that industry to make Bessemer's discovery. It was an innovation that could only have been made by someone from the outside who wasn't subject to job loss for trying the experiment.

Interdisciplinary study: it's not your father's Oldsmobile.

Generally speaking, software engineering environments, where by and large only the employees of Google are allowed to have original thought, do not take R&D seriously. Why? Partly because they don't demand an 80% failure rate. There actually IS an 80% failure rate in software development or close to. It's also called Power Law, the Long Tail, the Pareto Principle and the 80/20 rule. This damn thing gets around! Look how many names it has! Which is really just an effect of how frequently it shows up and in what a diverse set of environments. Unfortunately in software development instead of being an accepted phenomenon, it's mostly used as an excuse to harangue the employees for doing what is expected in reasonable environments.

Now I understand that not all software development environments are created equal and my comment about only the engineers at Google being allowed to have original thought is a bit strongly worded. That's deliberate. It's simply that while I believe the goal of slowing down a bit and encouraging each other to experiment and improve can be realistically achieved, I see very few companies adopting anything other than the "rush, rush, rush" approach and I don't feel that model is really serving us or our clients well as an industry. Rushing to get things done as quickly as possible doesn't encourage experimentation, skill development and thoughtful contemplation of design patterns, it encourage golden hammers and squelches innovation.

One question remains however. I wonder if it would be beneficial to the community (both the CF community and the onTap framework community specifically) for me to write up a tutorial or two about migrating an application from Mach-II or Model-Glue to the onTap framework? Something like Adrian's tutorials for converting a non-framework application to Mach-II? It could be a good way of showing comparative strengths and weaknesses of both frameworks in the process.

Yeah, I'm probably a little cocky, but really, I just like this play on words: "I'll bet a hammer of gold against your soul, 'cos I think I'm better than you." :)

Edit: Some very sobering examples of why we should "slow down" and experiment / practice / rehearse more can be found in this lecture presentation Software In Practice.