CODING METHODOLOGIES ARE A GOOD THING

As a developer with 8+ years experience now, I've worked in several different environments with several different coding styles and methodologies - sometimes the actively chosen methodology is "None At All". I've also been asked to take over many different projects at many different stages of completion, with wildly varying results.

Having just changed jobs, I now find myself in that familiar situation again - we have a large project just nearing completion, the client has asked for numerous amendments which must be completed ASAP, and the existing techies don't have the time to sit down and go through the codebase in any great depth with me.

Which brings me to my point - Coding Methodologies Are A Good Thing.

I should probably elaborate a bit here - I'm a web developer, and of the various programming languages I can program in, my primary skill is ColdFusion (CF), and my preferred methodology for CF development is Fusebox. I'm not going to get involved in the whole "is CF a 'proper' programming language?" debate here, or even the "my favourite methodology is better than your favourite methodolgy" slanging matches which frequently clog up the CF community forums. My point here is a general one - using ANY recognised coding methodology, even if it's customised, is nearly always better than having none at all.

I've heard many arguments against using methodologies, including the following :

1. "Why should we let someone else tell us how to do things?"


2. "I don't want to go searching through lots of little files for the bit I need - I want all the code for one page in one file, so I know where it is"


3. "We'd need training on it, and we can't spare the time or money for that"


4. "Fusebox (or methodology X) has too much overhead - we want to be able to totally fine-tune every single page for performance"

But consider this - at my previous job, there was no methodology in place. When I joined, we'd just taken over a complex online community application (which I shall refer to as Project X, to protect the guilty ;-) ). I was there for two and a half years, working on it every single day, and when I left, there were still great swathes of the codebase which no-one clearly understood and had to be treated like a black box. Ostensibly simple amendments would take days, sometimes weeks, and it was virtually impossible to have confidence in the code. Releases became a matter of "cross your fingers and pray that it works".

At my new job, I have just been handed the codebase for another complex online community application, similar to Project X but with even more complex functionality. However, THIS code was written to a methodology - a customised methodology, but still a methodology. One sentence was all that was needed to introduce me to the code - "it's Fusebox 3, but with CFC calls instead of act_ and qry_ fuses". This may sound like gobbledigook to the uninitiated, but with that one sentence, I instantly knew -

• How the directory structure of the code would break down


• Where to look for global-scope variables and module-specific settings


• How the framework of the application was put together


• How application flow would be handled


• That interface code would be almost completely separated from back-end code, greatly simplifying the task of amending either


• How the documentation would be structured


• Where I would need to look to find out any more information

Of course, as an experienced Fusebox developer, I had a distinct advantage over a non-Fusebox developer. But the point is that if it had been "CFObjects with X instead of Y" or "Struts with X instead of Y" or indeed any recognised methodology with some customisations, I could have spent a few hours getting up to speed on how that methodology works, and been able to make a start.

I produced my first constructive code within a few minutes of getting my hands on the existing codebase, and my first amendments went live within a couple of hours.

Now to address the arguments against methodologies listed above:

"Why should we let someone else tell us how to do things?"

Why not take advantage of other people's existing work in figuring out the framework, and let your developers focus on what the application needs to achieve, rather than how it should be put together?

"I don't want to go searching through lots of little files for the bit I need - I want all the code for one page in one file, so I know where it is"

Fair enough, but that one file may well end up several thousand lines long, performing many different tasks. Personally, when I need to amend some functionality, I would much rather be able to zero in on one small, distinct file that performs the specific task I am interested in. Maintenance and debugging become much more simple when you KNOW that you have, for instance, changed the interface code which displays the results of an information update, but you have not touched the code which performs the update itself, or the code which reads back the altered data. Especially in larger organisations, when many different developers need to work on the same areas of the application - often simultaneously - enforcing a physical separation of interface code from functional code, via a design pattern like Model-View-Controller or n-Tier prevents change management from spiralling out-of-control very quickly. It also facilitates developer specialisation - for instance, a developer who is strong on interface design but not so good at SQL can focus on display files without being distracted by all the back-end code, and vice-versa - in other words, you can focus on the task in hand.

"We'd need training on it, and we can't spare the time or money for that"

Many studies have shown that the biggest component of software costs is ongoing maintenance. A little investment now, in terms of training on a methodology, can pay HUGE dividends in terms of savings on maintenance. Also consider the time lost in training new developers on existing code - every hour spent reading documents or trawling through spaghetti code is an hour that could be spent coding those new amendments for the client.

"Fusebox (or methodology X) has too much overhead - we want to be able to totally fine-tune every single page for performance"

Yes, Fusebox, and probably every other common methodology out there, introduces a small overhead in terms of framework code, when compared like-for-like with a single file that performs the same task. But this overhead is minimal, of the order of a couple of milliseconds, especially with Coldfusion MX compiling code into Java and caching the compiled classes in server RAM. Besides, if your site has so much load that an extra millisecond or two on a page hit really is a big problem, then servers can always be upgraded - a thousand pounds spent upgrading the CPU and memory of a server is nothing compared to the savings made on developer maintenance time through using a known, flexible, extensible methodology.

It is well known that a common killer of software projects is so-called "Feature Creep", whereby more and more features are tacked-on to a system which ends up being almost unrecogniseable from the original specification, and often becomes a nightmare to maintain. As the complexity increases, so does the time required to add another feature, find and fix bugs, and train a new developer, often to the point of the system eventually being scrapped and replaced from scratch. Hal Helms, one of the original designers of Fusebox, has argued that Feature Creep is a perfectly natural phenomenon which can be accounted for early on in a project through the extensive prototype phase of the FLiP methodology (Fusebox Lifecycle Process). Having used this methodology myself, I can vouch for its effectiveness - the one project for which I was able to use FLiP in its entirety was delivered by a team of four developers, two weeks ahead of schedule, to complete client satisfaction, and to date has proved virtually bug-free. Using a standard methodology like Fusebox also means someone else has already done the dirty work of figuring out how to design for extensibility in the code, making future additions and alterations far less difficult.

Of course, I would never claim that any methodology is appropriate for every project - methodologies change, adapt, and evolve, as the limits of each are found, and new solutions developed. The latest version of Fusebox, which was intended to take advantages of the Object-Oriented (OO) approach inherent in Coldfusion MX Components (CFCs), evolved into something rather different - Mach II, an OO methodology utilising Implicit Invocation and an event-listener based architecture. The design of software methodologies, like the design of software itself, has been and always SHOULD be an evolutionary process. The choice of methodology for a particular project will always come down to a balance of existing skillsets, personal experience and individual preference - and there may well be a project out there which logically needs a completely individual methodology of its own, for which no existing architecture or design pattern will do, or can be adapted..... however, in eight years of designing and developing enterprise-class software projects, I haven't found it yet.