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.