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 arrived at Headshift, I now find myself in that familiar situation again - we have a large project in an advanced stage of development, the client has asked for numerous amendments and enhancements which must be completed quickly, and the existing technical team don't have the time to sit down and go through the codebase in any great depth with me.

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

I should probably elaborate a bit here - I started out as a back-office systems developer, then moved onto the web, 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 the "my favourite methodology is better than your favourite methodology" debates which frequently clog up CF community forums and usually end up in flame wars.

My point here is a general one - using ANY recognised coding methodology, even if it's heavily 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 one previous job, there was no methodology in place. When I joined that company, we had just taken over a complex online community application, which I shall refer to as Project X. 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 often became a matter of "cross your fingers and pray that it works".

At Headshift, I have just been introduced to the codebase for another highly advanced 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 had it 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.

As a result, I was able to produce 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?"

Try thinking of it this way instead - with just about any standard methodology, you gain support from an enthusiastic community of developers who are experienced in applying it to many common design situations, and are nearly always eager to help. Unless you choose an extremely new methodology, most of the bugs will already have been fixed, or at least, common workarounds found. Why not take advantage of other people's existing work in figuring out the gritty technical details of how the framework should fit together, 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"

This may well be a matter of individual taste, but that one file may easily 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 in parallel - enforcing a physical separation of interface code from functional code, via a design pattern like Model-View-Controller or n-Tier can help prevent 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 experienced with 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 architecting, developing and maintaining software projects, I haven't found it yet.