Firstly, I will apologize for the delay in my follow on article on Data Warehousing, it is in the works but delayed because I am trying to figure out a ludicrously complex in-house CF coding framework in use by a client I am trying to assist.
SD Times has been around for a while and I have always found it to be unbiased and objective or at least more so than most. This article by Andrew Binstock about CF8 was pointed out in an earlier blog post here but I thought it worth expanding on in the light of my years of experience in web application development.
One thing that made me sit up and listen, well read I mean, was the fact that Java Struts or its supposed successor(s) seemed to descend into confusion. The point that Andrew makes is that many companies out there have web applications that are hard to maintain and/or understand, he puts it this way – “The cost is significant: Many sites are sitting on reams of legacy code simply because they chose what was once the dominant paradigm.”
In my 8 years with Allaire, Macromedia, Webapper and now Alagad I have literally traveled the world looking at millions of lines of CF Code in no frameworks, home grown frameworks (the worst of all worlds) and recognized-supported frameworks. After all of this marinating and after listening to developers and end-users I arrived at my own golden-rules for web application development, here they are.
In developing applications we should start at the end and keep focused on the fact that we are delivering a GUI to users to enable them to do something easily and efficiently. We are not here to experiment with cool new stuff at the expense of users. Users do not care whether something is “procedural” or “OO”.
We should also assume that the code will need to be maintained and that this will involve troubleshooting. No matter what the requirements of the application are we should always strive to do this in the simplest most understandable way possible providing that falls in line with acceptable methodologies and frameworks currently used. Another so often ignored principle; comment code profusely. As has been stated many times by far greater brains than mine; not only will comments help others they will also help us when we look at what we did 6 months on.
Nothing should ever go into production without Integration Testing (making sure what we just did does not break anything else) and Load Testing (what works really well with one user “us” may fall apart quickly with multiple users – I have seen that many times).
The world of web application development is almost totally disorganized. For instance we could create a complete application in a single index.cfm in a single directory; there is nothing to stop us doing that. I have been a firm believer in web application code organization for many years and was firmly behind FuseBox because it made sense to me and has a good user base and had a formal committee which encouraged me to believe it would stay around. FuseBox in an MVC Design Pattern is still my preferred paradigm. I absolutely abhor in-house frameworks because they are not necessary and have nothing to do with helping application owners or users of applications. With FuseBox, Machii and Model-Glue and other items such as Reactor, Transfer, ColdSpring etc there is simply no justification, in my opinion, to create in-house frameworks or methodologies.
From the point of view, for those kind enough to pay me to enjoy myself and create things for them, I genuinely care about what I leave behind, that it delivers what users need/want, that it performs efficiently and above all else is easy to maintain, extend and fix.
I will finish this post with a repetition of Andrew Binstock’s point – “The cost is significant: Many sites are sitting on reams of legacy code simply because they chose what was once the dominant paradigm.”
I believe It is incumbent on all of us not to let this happen to those kind enough to pay us, even if it means being anarchistic to anyone pushing us to do what we believe to be the wrong thing. I certainly am and will continue to be so.
DougHughes.net 
Comments on: "In-House Frameworks And The Black Death" (19)
Why do you feel that homegrown frameworks are the worst? Just curious to see if your reasons are similar to my own.
LikeLike
Will, because when I went out for Allaire-Macromedia I had to figure things out very quickly and the hardest applications to deal with were always the ones sitting in some convoluted home-grown framework.
LikeLike
Good post doug!
The one thing I have to say from a home-grown frameworks perspective is that a select few of those home-grown frameworks became Fusebox, Model-Glue, Mach-II, etc. What point does a framework become “not homegrown”? Maybe when it is published on a site for download w/ documentation or other developers are using it? For that matter, who is qualified to write a framework at all?
That being said, I personally experiment a lot with frameworks, but am careful to not let those experiments end up in a client’s code or on a client’s bill. Anything that goes into a client’s code should always be production quality and deeply considered in terms of future maintainance.
Mike.
LikeLike
Mike, you make good points regarding the crossover from home-grown. I personally used two major considerations when looking at frameworks. Firstly can I understand them and secondly do they have appear to have community support? One of my favorite reference points in all of this is Sean Corfield. Because I know he will give an unbiased view and I recall he was very leery of frameworks for CF so has not reason for bias.
LikeLike
I disagree with your view on home grown frameworks.
Andrew Binstock is talking about ColdFusion as the framework not FB or MachII etc.
Adopting FB or MachII or any other CF frameworks can lead to the same situation he describes for java frameworks.
I think the point he is making is that with CF you can deliver solutions quickly and easily.
For me it comes down to how much time you have to spend learning and maintaining the framework vs delivering the solution the customer cares about.
LikeLike
Johan thanks for your comment and yes my reference to the article is a bit obtuse, it is more that that particular sentence in the article reminded me of the predicaments I found many clients in. Of course not all of those predicaments were totally the cause of home-grown frameworks. What I have definitely seen is the proper use of a framework in wide use in the community does help those familiar with that framework to get up to speed quickly and to figure out what is going on in an application.
LikeLike
Call me crazy, but I think this might be a clarification of what you’re driving at:
1. Yes, all frameworks start out as someone’s idea for their current development site.
2. Some of these suck, some don’t.
3. A developer willing to shove it out there (FB, MG, M-II, ColdBox) means there’s something to it.
4. At that point, people either learn it, adopt it and, as a community, better it.
5. …. or it dies out before it hurts others.
Sound about right?
– Will B.
LikeLike
Will thanks for taking the time to comment again and your thoughts are pretty much what I was trying to say except the in-house frameworks that don’t make it are often still embedded in many applications I have seen. If I were a company either employing or using developers I would very much want to know what they are doing in my applications.
LikeLike
I wanted to make one more comment to my own blog post ;o) which came to me whilst ruminating last evening. The worst kind of in-house frameworks I have dealt with are those which are contained inside the application code. Frameworks should contain applications and not the other way around. We might characterize the worst offenders as INTIMATELY coupled.
LikeLike
As a framework evangelist, I feel I should comment (partly because Mike invoked my name!).
I generally approach any framework from a skeptical point of view – even tho’ I am a huge fan of (good) frameworks. As a freelance consultant (now) I’m also getting to see a lot of code out there and some of it is built on homegrown frameworks. A couple of such systems are labyrinthine beyond all measure and a non-framework version of the code could not possibly be harder to follow.
The rough fact is that very few developers are actually capable of building a framework that can stand the light of public inspection and any framework that can’t pass that is likely to get you into trouble.
That said, some developers manage to dig themselves into terrible holes even with the public frameworks 🙂 I reviewed a terrible Mach-II application a while back and, at the same time, a Fusebox 2-ish application from the same developers that was really clean and easy to understand – and I think that speaks to the importance of picking a framework that matches your skill set.
Mike’s last point is very important: a framework should be a clearly identifiable piece of code that sits “outside” the application (i.e., in easily identifiable files that don’t directly contain application logic, even if it isn’t physically separate from the application code).
LikeLike
Sean you made an excellent point here which I overlooked. Using a recognized framework (Machii for instance) is not a guarantee that all in a particular application will be great. It is entirely possible to use a good framework and still ruin things. One other point I did not amplify, taking a recognized framework and altering the core or internal workings is another unnecessary and often potentially disastrous step.
LikeLike
I think this really comes down to “good frameworks are good, bad frameworks are bad” and “bad programmers can do bad things – even with good frameworks”.
There is clearly a correlation between good frameworks and open source frameworks, but I bet you could find some crusty frameworks on RIA Forge if you looked hard enough – making something OSS doesn’t make it good per se.
If a framework becomes a successful community framework, a lot of people have put a lot of time into creating a great resource that others have found valuable enough to use, so the “cream” clearly rises. There are also additional benefits using a community framework as you don’t have to develop it from scratch, there is often a pool of talent trained in it and there is sometimes pretty good documentation as well.
All that said, there is NOTHING wrong with an in-house framework – just so as it is enough better than the community frameworks for your use case to justify the time and effort to develop it, document it and train people in it. Of course, the vast majority of home grown frameworks don’t get over that hurdle, but the blanket assumption that “home grown = bad” is wrong. (Although I’d concede that in MOST cases open source is better than proprietary.)
LikeLike
Whilst I agree that “home grown = bad” is not a truism, two major disadvantages are that you have to train every new developer that joins the team and you get only minimal feedback on the framework (because only a very small pool of people are using it) so it’s really hard for the framework to grow and improve.
Certainly, not all open source frameworks are good – there are a lot of projects that have essentially died on vine out there – but the size of the community is a good indicator of that, an active mailing list / forum, current documentation etc.
I put stuff out there as open source for two reasons: it might help someone avoid reinventing a wheel; the feedback I get makes the project better which helps me build better apps. That second reason is very, very important to me! 🙂
But I will also admit that I put some projects out there simply because they’re kinda cool examples – I have no idea whether anyone will use them (I’ve been pleasantly surprised with the feedback on both my Concurrency package and my Closures package, neither of which I actually expected to become popular).
LikeLike
And a footnote to the “train every new developer” issue is that developers tend to set less value on training that they can’t carry on to a future job – it’s very unlikely that other developers will care as much about your framework as you do. That’s not true of popular open source frameworks where knowledge is both portable and valuable (have you seen the rise in jobs requiring experience in those frameworks?).
LikeLike
@Peter I respect what you you have to say, as always. Can you think of any justification for creating an in-house framework when there are already what I believe to be adequate ones out there is use by the community?
@Sean, you make two key points here. Firstly adding developers familiar with a recognized framework to a project where that recognized framework is in place is much more productive, from the get go. I have seen that many times. Secondly, being familiar with a recognized framework as developers absolutely makes us more marketable.
LikeLike
@Mike,
Sure, I have a pretty good use case. My goal is to be able to generate 10,000 custom web apps a year. I have created a software product line with a collection of Domain Specific Languages for describing objects, relationships, properties, validations, transformations, imports, exports, basic reports, screens, actions and steps. A metabase allows for reuse of packages of functionality by re-using collections of essential and optional statements in the DSLs so you have the benefits of reusable modules without the limitations of actually coding them in a 3GL.
On top of that I’m developing a system for automating the transformation of statements in DSLs between versions by describing the required transformations in a formal manner so I’ll be able to port thousands of custom apps between framework versions as my grammars evolve with either no human intervention or with a web based interface to allow the handling of the decisions required by certain classes of transformations that can’t be transformed automatically.
Underlying this I have a custom framework that currently interprets XML descriptions of the DSLs to provide rich applications which are primarily “programmed” using the DSLs but which can be very easily and cleanly extended using small amounts of custom code where required. I looked VERY seriously at ColdFusion, Python, Ruby and Java frameworks (I was seriously considering porting to a generation based solution to gen Java code just to have full access to Hibernate), but I have found that my completely custom framework fits my use case perfectly. The ability to write a combination of framework and/or code generators to map exactly to my DSLs has been invaluable allowing me to create a system meeting all of my needs in just a few thousand lines of ColdFusion code. I did spend quite a bit of time looking at how I might be able to save effort by just wrapping (say) Transfer and Model Glue, but there were important distincitons between the models in my DSLs and the approaches those frameworks took and I found it easier to create my own completely custom framework than to try to force the community frameworks into my somewhat unique use case.
I also now have the benefit that I conceptually “get” the algorithms for my controller, custom data types, ORM, data mapper and other capabilities, so I’ll be able to work with developers to allow for the “write once, deploy to n-3GL languages” capability which I’m going to need (eventually I’m going to have to be able to gen at least PHP, Java and C# as well as CF).
The effort put into creating really elegant, usable DSLs was so large that the effort of writing the custom frameworks was a small part of the work required, I would expect to be able to maintain the core framework with a very small team and we’re developing a web based interface for building apps and have a very clean, easy to learn API for the implementers we’ll have to hire as we scale the business.
As for open sourcing, we believe there’s substantial business value in what we’ve created (and I’m presenting this at major code gen conferences and getting very good feedback from respected experts in the field, so we’re not just another “gee I wrote a code generator” group) and I’d like to go make a pile of money by commercializing it.
To give a sense of how disruptive this could be, for clients that have a decent sense of their objectives, we’re trying out a model where we sit down with them to elicit requirements, build them a custom web app and they only have to pay for it if they want it. Looking at the higher closing rate and the roughly comparable effort for us between generating proposal and generating the application, I think we might be able to pull this off.
Of course, we only do smaller projects (typically $10,000 – $30,000) with limited non-functional requirements, but for our target audience it’s looking promising so far. Just starting to market, so I’ll let ya know how it goes!
LikeLike
Thanks Peter your piece is much better than my original post I hope others get the chance to read it. Do you have any thoughts or input as to how easy web applications created from your system would be to troubleshoot if problems should occur? I ask that question because without something like SeeFusion framework based apps can be really tough to diagnose.
LikeLike
Hi Mike,
Great question! And unsurprisingly, the answer is “it depends”!
The first thing to remember is that as more programming moves from the 3GL to a colleciton of DSLs, you need to create debugging tools for your DSLs. I’m working on continually making my DSL validations richer. One of the reasons they go through XML is to allow me to use schemas for “validation in depth” to catch a lot of silly “programming” errors in the DSLs and I’m working up a better interface with a richer semantic understanding of the DSLs (I’m still working on patterns for this – it’s a non-trivial problem in the general case) so it can catch more bugs before they are run. As for 3GL code, because it is so clearly constrained by the framework (you can add code to custom service classes, DAOs, business objects, controllers, layouts or data types as well as to extend some base libraries for things like validations and transformations) so it is usually very easy to instrument and catch regular errors in your code.
As for debugging the framework, all I can say is it gets more solid with each project and I’m trying to increase both unit and integration test coverage when I get spare time which should help. Otherwise I use the same kind of cfdump/cfabort that many do in lieu of a debugger (I know there’s a good line debugger in CF now, but haven’t had a chance/need to play with it yet).
As for the subtle problems that came come up occasionally due to load or weird problems with the JVM, all I can say is I have been lucky not to have any such problems yet. Hopefully with the framework being so intrusive and opinionated any such problems will be to do with the framework (but will only show up in special cases of certain projects). This means I should be able to fix such problems once and then be done, but I could well need a copy of SeeFusion before I’m done.
My other dirty little secret is that most of my clients just don’t have any load. I can usually put 30-40 clients on a server and be running 2-5% CPU utilization on a $1500 1U SuperMicro running Win2003 Web Ed. I tend to avoid higher traffic projects as (i) I’m not an expert in such issues and (ii) such people are usually not going to be happy with the help they’re going to get from me for $15,000 if they need an n-server load balanced system fully set up with monitoring and load testing and the like in addition to project management, graphic design, data entry and specifying and programming the app. My opinion (and I may be wrong) is that you need at least a $50,000 budget to end to end specify, design, build, configure, load balance and deploy a system that’s going to handle real load with mirrored db servers and load balanced web servers, and that’s out of the price point that we play in.
Just to ask someone who knows way more about this than I do, would you take on an entire (project management, data entry, graphic design, programming, testing, load testing and deployment) sophisticated e-comm app which needed to handle real load for much under $50,000 end to end? If so, I need to rethink my position and dust up on my HA knowledge!
LikeLike
stupid
LikeLike