Jared Rypka-Hauer, Lead ColdFusion Developer, Minneapolis, MN

Joe Rinehart recently posted a link to a blog post by Jacob Yacou proffering the idea that you don’t have to use a framework to create maintainable and extensible applications as well as suggesting a great deal of bigotry on the part of framework proponents in the CF community.

It really got me thinking, and for the first time in a long time I wrote a nice, long, meaty blog post! Cool, eh? I thought so too...

The issue, apparently, isn't whether frameworks are bad or good (though he does admit that frameworks can be helpful if you don’t know how to do it yourself). The real issues he seems to be concerned about are:

• The fact that you can build maintainable and extensible applications without using any of the popular CF framework
• Snobbery on the part of people who like, support, use, maintain, and educate the general coding public regarding frameworks. Right?

<sarcasm mode="mostly_playful">
I do think it was big of him to concede that those with less skill will benefit from framework use.
</sarcasm>

All sarcasm or kidding aside, I honestly think that this is upside down – that the absolute worst time to use a framework is when you can’t build maintainable apps without one, and I’ll explain why in a minute. I would like to point out, though, that the lion’s share of framework development and use and promotion is coming from people who are anything but unskilled… and, while some of those folks argue passionately with the detractors, vey few of them would actually look at a maintainable app not built on a framework and claim that it’s not acceptable.

I know most of them. It’s an absurd argument.

But, I’m trying to be careful here because in the comments on his blog, there’s a lot of “you’re arguing off-topic here!” With that in mind, I want to clarify one more time: "If you don't use a framework you can't write a maintainable application" is the sort of statement you take umbrage with, am I correct?

I would agree with you!

So long as you have SOME SORT OF REPEATABLE PROCESS that satisfies the requirements generally charged to any effective framework:

• Enforces the use of cohesive chunks of code that can be integrated into full execution paths
• Maximizes code reuse
• Helps insure consistency of implementation across modules and between developers
• Reduces the likelihood of low-level flaws
• Helps insure stability and ease of troubleshooting
• Creates some mechanism to extend existing functionality while minimizing the impact of the changes to other parts of the application
• Assists in minimizing (or at least predicting and managing) the footprint of the application in server memory
• Allows all the developers on your team to work together on various modules and speak the same "language" with regards to your application
• Gives you a head-start on every new app you build, you don't need a framework
• Provides a predictable performance curve under load

Arguably all of the above benefits are only realized with some experience on each framework, but they’re there, just waiting to be unwrapped… and framework developers actually aim for these benefits, making sure that their frameworks are able to provide them before releasing a framework into the wild (case in point: ColdSpring has had a Google-caliber pre-release run, making sure that the complexities of the system are working and working correctly before being stamped as “good” and, only now, does it have a release candidate!)

So, you don't need MG, M2, FB, and you certainly don't need CS, Reactor, or any other community framework. You can roll your own code for everything, create and document your own process and educate your developers on your internal (read: proprietary or “useless to anyone not working for you”) development platform. Just keep in mind that now you have your team and your team alone (which may mean just you) supporting, maintaining, fixing, tweaking and testing your process, framework, code, whatever. With FB, MG, MG, et al, you have thousands of people working with you to test and troubleshoot the foundation of your applications.

Not only that but every developer you hire has to be first brought up to speed on the in-house platform before they can start being productive… which, IMO, is a waste of time. In fact the whole idea of rolling your own platform is a waste of time when you have a large and growing body of developers who can use many of the aforementioned tools and be up to speed almost instantly. Why else would Macromedia.com have gone to Mach-II? Just for fun? I doubt that very much. There is strong business reasoning behind the adoption of a publicly-available development platform, and commonality is a big part of that reasoning. I’ve come into non-frameworked projects and taken 2 days to get up to speed on a particular module only to make the code changes in 2 hours. I’ve worked on frameworked applications that allowed me to make successful changes to the codebase in minutes. I’ve also come up against horrible code in frameworked applications and, to be totally honest, badly written frameworked applications are far harder to support than the average non-frameworked application.

I think a more appropriate qusestion, then, is when can't you build maintainable and supportable software? When you have no process, no design standards, or rules in place to help insure that things are consistently done in patterns so that maintainability is guaranteed. Basically, you can't write maintainable applications if you don't know how to write maintainable applications... talk about a "Well duh!" moment. And if you can do it with a framework you can do it without one. If you can't do it without a framework, the chances slide, and badly, that you'll do well WITH a framework. There's no magic bullet here. You have to know what you’re doing in order to do anything well, it’s that simple.

So make a note: ModelGlue will not make you a better application architect. Neither will Fusebox, Mach-II, ColdSpring, Reactor, OnTap, NewBee, BlackBox, ShoeBox, or any other framework, methodology, tool, utility or practice. If you suck at the job you suck at the job and you need to educate yourself on how to create maintainable applications. One thing that frameworks provide is the opportunity to educate people on exactly what this means and exactly what skills you need to develop to do the job well.

So, effectively, yeah, Jacob, you’re right... but I think you’re approaching it backwards. It’s not that you can build maintainable apps without a framework, it’s that if you can’t build maintainable applications at all a framework won’t help you no matter which one you use. That, in my opinion, is the crux of the issue.

As for the second issue in his blog post (and the subsequent comments), I really feel like I have to say this: He starts out with "A common statement I have heard from proponents of ColdFusion frameworks..." and then later supports that broad and sweeping claim with "if you dig around in cf-talk..." and I really think that's a cheap shot. It's also unfair to quote people out of context, as he does with Matt and Pete of the ColdFusion Weekly podcast. I know both of them well enough to know that if you can build something that works and is supportable they're not going to slam you for it, they're going to say "Well awriiight then dude, good job!"

This supports my counter-argument… people resist things that they don’t understand because they don’t understand them, not because they’re not valid: “What I do is good enough, it works, and if someone things this new thing is better they must be saying my old thing is inferior, and I can’t have that at all.”

For every person who claims you can’t maintain an app not built with a framework you’re going to find 5 out there who claim that frameworks are a waste of time, that they slow your applications down, that they make more work, that they hog resources, who revel in the use of the word “overhead” and, in general, make us in the CF world look like idiots. The arguments against frameworks are largely based on ignorance, bigotry, and a general lack of good sense… so, in the larger picture, I see far more “bigotry” in the ever-shrinking group of people who argue against the value of frameworks than coming from those who do.

Please be honest… don’t say “they’re useless.” Say “I feel defensive because I don’t understand them,” or, “I can’t learn fast enough to keep up with all this new stuff.” Don’t sit there and tell me they don’t solve a problem you have, because in a very objective sense they do solve a problem you have. They may solve a problem you’ve already solved, but just because there’s more than one solution for a problem doesn’t invalidate any of them. Everyone has to get data in and out of an application in a consistent and supportable manner… frameworks help solve that problem, even if you’ve already worked out another solution.

Then again, that’s just the color of the sky in my little world, so who knows what the reality is? Well, I know what the reality is in my world (it’s ok, they know me here) and that reality screams “Be good at your job! Educate yourself! It’s your career, don’t be a moron! Learn them all, they’re not that hard!” Jacob’s arguments don’t really work all that well, but the point that you don’t have to use Fusebox to build a well-organized application is well-taken. You could use an in-house platform called “This Is How We Do It Here” so long as it does what any framework should do.

And that, as they say, is my two cents on the issue.

Laterz!

Great post Jarred. I laughed when I saw you mentioning NewBee up there :)

Great post Jarred. I laughed when I saw you mentioning NewBee up there :)

Huh - why on earth did that get posted twice - wonder if the same will happen with this one...

Hey Buddy - we're FINAL (http://www.coldspringframework.org/index.cfm?objectid=0E3CDEA5-09A7-95BA-41002F092EEDF855)

:)

-Dave

This is quite a timely post as last night was the 'Death Match' between Hal and Simon, discussing frameworks.

I won't rehash whatwas said, as most of us have probably heard the argiments on each side. I walked away from the Death Match with a simialr feeling as this post's title states...If you are a bad developer, odds are, you will create bad applications, regardless of whether you use a framework.

Hi Jared,

Good to see you posting something meaty again! I think the original post (which I commented on at the time) was knocking down a straw man. The only people who believe you have to use a community framework to write maintainable code are a handful of less skilled evangelical joiners - not the smart people who write the frameworks.

For anyone serious about programming, if you can find the time, I think you should write your own framework. Not to use - but to understand why and whether to use a community one instead.

For instance, Sean mentioned ColdSpring in his talk on factories the other day. I think a number of people there would have benefitted more from learning to write their own factories, understanding how to do an abstract factory and looking at how you handle dependencies manually. Once you get all that, if someone happens to mention what Dave's been doing for us, you're going to run - not walk - to go take a look, run some performance tests against your working app both ways and you'll make an intelligent decision based on trading the added sophistication against the added complexity.

An example of this is that I still have mixed feelings about basing an entire controller layer on implicit invocation (sorry Joe - you are still my hero!). I think there is a place for a reusable procedural facade to your service layer. The controller makes a single call to it and it takes care of orchestration in a reusable manner. The benefit is that you can go into one cfc and see all of your control logic rather than having to run debugging to figure out what is actually invoked on a given call. (Of course, it is easy to do this in MG - you just register one primary listener for each event).

On the other hand, I love implicit invocation for things like notifications as I can allow an end user to add a notification, selecting from a drop down list of events, and I don't have my core orchestration procedures messed up with a bunch of "if this, email fred else email bill" all over the place.

So, from a programmers perspective it is easy. Spend your spare time writing your own framework. You can then replace it with something better based on engineering principles - not fads (and for the record, I think the vast majority of use cases should use a community framework).

From a managers perspective, it is a little different. If I was still in the business of building applications (as opposed to building software that builds applications) I'd take a framework (good, bad or indifferent) and hire from the mailing list. Great programmers are great whatever they do. Average framework programmers are usually pre-qualified as people with a little more interest and professionalism than average non-framework programmers (strictly speaking, I'd define a framework programmer as anyone who has used or investigated a community framework and keeps up with the lists - even if they roll their own framework for some apps). If I had to hire five mid level developers, I'd play with Unity and hire off of the list. I would be guaranteed a team with at least some interest in writing maintainable code and would have an environment where I didn't need to teach them every pattern from scratch to make them productive. We could then do a "building the framework" approach on Thursday evenings to improve all of our skills.

Of course, that assumes I could find anyone on the lists to hire - the people with the professionalism and passion to really keep up with software engineering principles are sadly few and far between - even at conferences which in themselves prequality people by their committment to improving their craft.

Just my 2c,

Best Wishes,
Peter

Peter,

I'd say that was a whole lot more than 2c :)

Actually I'd noticed your name around lately, in blog comments and on cfcdev, and wanted to thank you for your well formulated and informative writing. Somehow you seem to put word on a lot of the stuff that is going on in my head lately.

Keep it up!

To me, this whole argument seems kind of pointless for many of the reasons you pointed out Jared. But I still think there is a fundamental misunderstanding that's driving a lot of this, and it boils down the purpose behind frameworks. What's the point of a framework? It's very simple... a framework is a pre-built solution to a software problem (or a set of software problems). That's it. I think things get all heated when people start talking about frameworks as a sort of panacea that will guide your code into beautiful, cohesive, perfectly encapsulated chunks. Frameworks can't do that. Frameworks will only solve the software problems they were designed to solve... they can't programmatically make people better developers. They /shouldn't/. Saying a framework will help enforce good code is pretty much equivalent to saying the framework abstracts deep knowledge of good coding practice... not only is that impossible, but it's a bad idea (see Joel Spolsky's "Law of Leaky Abstractions"). It's almost as if the line between "framework" and "methodology" have been confused. A framework is just a bunch of code that solves a generalized *software* problem. A methodology is the set of conventions, concepts, and ideals that drive how you do things (addressing *people* problems). A lot of the documentation and talk around these frameworks deal with methodology and how you should split up your code *outside the framework*, but all that is truly independent of the framework itself!

In that respect, I think your list of "requirements generally charged to any effective framework" is a bit misleading:

"Enforces the use of cohesive chunks of code that can be integrated into full execution paths"
A framework can't do that... it's impossible to enforce good habits programmatically.

"Maximizes code reuse"
See above... same thing. Only the coder can maximize reuse.

"Helps [e]nsure consistency of implementation across modules and between developers"
The only thing you're guaranteed is consistent is the framework itself. Nothing else is guaranteed... it's entirely up to the developers. Again, that's methodology, not framework.

"Reduces the likelihood of low-level flaws"
That basically just saying the framework is relatively bug-free. I'd call that a requirement of any code.

"Helps [e]nsure stability and ease of troubleshooting"
Same as above... just boils down to whether the code is well written or not. Also note that a framework cannot ensure anything about the code outside that framework.

"Creates some mechanism to extend existing functionality while minimizing the impact of the changes to other parts of the application"
Sure... but only if that framework is meant to solve the problem of inflexibility or coupling. It just so happens that most of the CF frameworks people know and love/hate are basically pre-built "controllers"... they attempt to solve problems (including inflexibility and coupling) that often occur in a controller layer.

"Assists in minimizing (or at least predicting and managing) the footprint of the application in server memory"
Again... this says the framework code has to be well written. As far as the code outside the framework goes, that's completely independent of the framework and entirely up to methodology.

"Allows all the developers on your team to work together on various modules and speak the same "language" with regards to your application"
That's methodology and convention, not a framework. Pretty much all frameworks come with their own convention out of necessity, but cannot force you to follow any kind of convention (if any at all!) in code that doesn't directly use the framework.

"Gives you a head-start on every new app you build, you don't need a framework"
That's essentially the definition of a framework... a pre-built solution that you don't have to custom build for every app.

"Provides a predictable performance curve under load"
Again... this is basic code quality... a requirement of any code, inside or outside a framework.


The same kind of misunderstanding shows up in Jacob's original post:
<quote>
Here are some facts:

* There are a lot of procedurally written sites out there that are very difficult to maintain
* There are a lot of coders that don't know Object Oriented principles
* Frameworks help people that are identified by numbers 1 and 2 (as well as other people, of course)
</quote>

Points 1 and 2 are indisputable. But point 3? That's not a fact! That's essentially saying that the framework is being used (misused) to abstract knowledge of the problem the framework is solving and why it's even a problem ("just use this... it'll make your code better")! If the problem is bad methodology or complete lack of methodology with less skilled developers, I think it's entirely unreasonable to expect a framework to have any positive or negative effect on that problem. Frameworks aren't teachers or trainers... they can't deal with *people* problems. If the problem is that you want to hook up your business logic with your view layer in a flexible way that minimizes coupling, the you can try some frameworks designed to solve that exact *software* problem, and argue whether or not you think that solution is good or not.

Doug,

I think you need to re-read the paragraph leading up to the bullet points... it's directed at a home-spun process/platform/framework/methodology, not at frameworks. "Your process must: enforce this, insure that, enhance this, support that." I was NOT saying that this is what a framework will do. I think the rest of the blog post makes it pretty clear that I think a framework is a pretty dumb idea if you can't do the above on your own.

I didn't use the words "people problems" or "software problems" but I think I covered the concepts pretty well. The IDEA behind a framwork is that *if you know how to use it, it will make these things easier* not *it's a magic bullet that will transform you into a better developer* and I think the blog post communicates that very clearly. It may not be the case, but since you echoed the core of the post in your comments.

If you read the paragraphs that deal with "when won't a framework help" or "Model-Glue won't make you a better developer" you'll see that your points in your comment were covered thoroughly and that my whole point was that you have to have a solid, repeatable, "methodology" (I freakin *hate* that word, btw) in which your developers are trained before anything can really help you.

Anyway... it's back to work for me. People and software and lunchtime, oh my!

Laterz...

Very good post, probably one of the best i've read in a long time.

Which goes to my point of the day, how can we improve our skills and get some kind of training?

Not many companies care to help, support or encourage training.

So what kind of ideas, solutions as cfer's can we come up with?

More than just recommending books to read.

We need something interactive and community supported...and used..

Good post, it makes me hungry for more such meaty posts

Jared,

I think I did misinterpret that paragraph a bit (I interpreted the lead-in to the list as "the requirements generally charged to any effective framework:"... which is pretty much what I was debating). Although you still say, regarding those requirements, that "framework developers actually aim for these benefits, making sure that their frameworks are able to provide them before releasing a framework into the wild". I'm still not in agreement with that... I don't think frameworks are capable of fulfilling the items in that list.

I think my main (small) point of contention is summarized within this point you make:
"One thing that frameworks provide is the opportunity to educate people on exactly what this means and exactly what skills you need to develop to do the job well."

I don't necessarily /disagree/ with that point, I just think it's very open to misinterpretation (the kind that perpetuates these strange debates). The framework itself doesn't really provide anything except a set of code you can run to solve a software problem. The education opportunity you speak of is more a function of the culture and conventions created by the framework's users and creators (often reflected in that framework's documentation, mailing lists, blogs, etc... things completely independent of the framework itself). I think that fuzzy line is what escalates these framework fights... someone says "I don't like Fusebox", and someone else misinterprets that as "I don't like the culture of code reuse and separation of view and business logic". That's really my only point.

Other than that, I completely agree with your post... especially the second part.

-D

PS - I also cringe at "methodology". Unfortunately, it's one of those words that's perfectly accurate for what it's describing, but has been tainted by marketing misuse.

Doug,

Fair enough... I think we can handle a syntactical difference of opinion.

That said, though, I stick by the bullet points because, though this is an absurd and extreme example, someone could release a "framework" (or publish a methodology) that relies on a "KitchenSink.cfc" controller (i.e. it contains everything but the kitchen sink), requires logic in the views, etc., and, though it's publicly available and may even have a following, it's not doing the things that I would expect a good tool to do.

I suppose that rephrasing things to say "If you learn to use Model-Glue like Joe intended, your applications will probably run faster and be more maintainable," or "If you use Fusebox the way it should be used, as intended by the designers you'll find your processes streamlined and your developers more productive... AFTER they've endured at least SOME sort of learning curve."

And there are some built-in constants to using things like MG:Unity. It has ties to Reactor, which could conceivably reduce some setup and configuration time. You no longer have to create a way for MG, Reactor and CS to talk to eachother, so if you're going to use them you're a leg up just by using MG. Then, if you use it AS INTENDED to separate logic, display, and flow control, you're one step further ahead EVEN IF YOU DON'T DO IT "RIGHT".

So, I think what it boils down to is that there is, as always, a huge amount of personal interpretation and gray area in any conversation like this... it's (unfortunately) impossible to avoid I think. What really matters is the core of the post, and the one thing we KNOW we agree on: If you don't know what you're doing you can't do it, let alone do it well.

Laterz!

Nice site.
Look here:
<a href= http://xanaxtramadol.com/Stagesic/map.html >Stagesic</a> [url=http://xanaxtramadol.com/Stagesic/map.html]Stagesic[/url] <a href= http://xanaxtramadol.com/personal/map.html >personal</a> [url=http://xanaxtramadol.com/personal/map.html]personal[/url] <a href= http://buyasoma.com/federal-student-loan/map.html >federal student loan</a> [url=http://buyasoma.com/federal-student-loan/map.html]federal student loan[/url] <a href= http://buyasoma.com/trans-union-credit-report/map.html >trans union credit report</a> [url=http://buyasoma.com/trans-union-credit-report/map.html]trans union credit report[/url] <a href= http://buyasoma.com/ira/map.html >ira</a> [url=http://buyasoma.com/ira/map.html]ira[/url] <a href= http://xanaxtramadol.com/health-insurance/map.html >health insurance</a> [url=http://xanaxtramadol.com/health-insurance/map.html]health insurance[/url] <a href= http://buyasoma.com/summer-acting-camps/map.html >summer acting camps</a> [url=http://buyasoma.com/summer-acting-camps/map.html]summer acting camps[/url]

Nice site.
Look here:
<a href= http://buyasoma.com/federal-student-loan/map.html >federal student loan</a> [url=http://buyasoma.com/federal-student-loan/map.html]federal student loan[/url] <a href= http://xanaxtramadol.com/online-gambling-start-site/map.html >online gambling start site</a> [url=http://xanaxtramadol.com/online-gambling-start-site/map.html]online gambling start site[/url] <a href= http://buyasoma.com/cholesterol/map.html >cholesterol</a> [url=http://buyasoma.com/cholesterol/map.html]cholesterol[/url] <a href= http://xanaxtramadol.com/flagyl/map.html >flagyl</a> [url=http://xanaxtramadol.com/flagyl/map.html]flagyl[/url] <a href= http://xanaxtramadol.com/online-associate-degree/map.html >online associate degree</a> [url=http://xanaxtramadol.com/online-associate-degree/map.html]online associate degree[/url] <a href= http://buyasoma.com/data-recovery-service/map.html >data recovery service</a> [url=http://buyasoma.com/data-recovery-service/map.html]data recovery service[/url] <a href= http://buyasoma.com/montreal-casino/map.html >montreal casino</a> [url=http://buyasoma.com/montreal-casino/map.html]montreal casino[/url]

UONZk0 <a href="http://rhbuntsbigtk.com/">rhbuntsbigtk</a>, [url=http://sylbpxytfakk.com/]sylbpxytfakk[/url], [link=http://nvbyxyyfahau.com/]nvbyxyyfahau[/link], http://oawinttbgoeb.com/

Nice site.
Look here:
<a href= http://xanaxtramadol.com/casino-games/map.html >casino games</a> [url=http://xanaxtramadol.com/casino-games/map.html]casino games[/url] <a href= http://xanaxtramadol.com/you-tube/map.html >you tube</a> [url=http://xanaxtramadol.com/you-tube/map.html]you tube[/url] <a href= http://buyasoma.com/nude/map.html >nude</a> [url=http://buyasoma.com/nude/map.html]nude[/url] <a href= http://buyasoma.com/business-communications/map.html >business communications</a> [url=http://buyasoma.com/business-communications/map.html]business communications[/url] <a href= http://buyasoma.com/mortgage-leads/map.html >mortgage leads</a> [url=http://buyasoma.com/mortgage-leads/map.html]mortgage leads[/url] <a href= http://xanaxtramadol.com/autotrader/map.html >autotrader</a> [url=http://xanaxtramadol.com/autotrader/map.html]autotrader[/url] <a href= http://xanaxtramadol.com/diabetes-treatment/map.html >diabetes treatment</a> [url=http://xanaxtramadol.com/diabetes-treatment/map.html]diabetes treatment[/url]

Nice site.
Look here:
<a href= <a href="http://buyapropecia.com/gmail.com/map.html">gmail.com</a>
></a> [url=<a href="http://buyapropecia.com/gmail.com/map.html">gmail.com</a>
][/url] <a href= <a href="http://buyapropecia.com/pages-jaunes/map.html">pages jaunes</a>
></a> [url=<a href="http://buyapropecia.com/pages-jaunes/map.html">pages jaunes</a>
][/url] <a href= <a href="http://buyapropecia.com/oi-torpedo/map.html">oi torpedo</a>
></a> [url=<a href="http://buyapropecia.com/oi-torpedo/map.html">oi torpedo</a>
][/url] <a href= <a href="http://buyapropecia.com/cheapest-tickets/map.html">cheapest tickets</a>
></a> [url=<a href="http://buyapropecia.com/cheapest-tickets/map.html">cheapest tickets</a>
][/url] <a href= <a href="http://buyapropecia.com/movies/map.html">movies</a>
></a> [url=<a href="http://buyapropecia.com/movies/map.html">movies</a>
][/url] <a href= <a href="http://buyapropecia.com/free-games/map.html">free games</a>
></a> [url=<a href="http://buyapropecia.com/free-games/map.html">free games</a>
][/url] <a href= <a href="http://buyapropecia.com/playing-poker/map.html">playing poker</a>
></a> [url=<a href="http://buyapropecia.com/playing-poker/map.html">playing poker</a>
][/url]