Recently, someone e-mailed CF Advisor's Fusebox Columnist, Hal Helms, posing the question, "Why is Fusebox important?" At the recent Allaire Developer's Conference in Boston, Hal addressed that question when he spoke before 300 people at a special interest group session. And he also shares the answer here.

Why is Fusebox important? To help answer that question, let's explore the similarities between the state of software development in 2000 and the state of rifle making exactly two centuries ago in 1800. What are the noticeable qualities both share?

• Skilled craftspeople are needed to create the product.
• Each product is a unique work of its creator.
• There is a shortage of skilled workers.
• There is a wide variation in the quality of finished goods.
• Maintenance of our products requires the user to go back to the creator or to employ the skills of a highly-paid master craftsperson.
• There is very limited division of labor.
• There is little efficiency of scale: it takes 10 times as long to produce 10 products as one.

Two centuries ago, the emerging government of the United States needed rifles. But rifle making was a slow process requiring highly trained craftsmen. Into that situation stepped an American genius named Eli Whitney. Whitney had already produced the cotton gin when he proposed to the government that it contract him to produce ten thousand rifles at a cost of $13.40 each, to be delivered in two years. The idea was so preposterous that only his reputation as "the man who can make anything" won him the contract.

Of course, Whitney went on to revolutionize rifle making--and in general the methods of production--by the simple idea that the component parts of an object should be so clearly specified (by means of a template) that a worker could be trained on creating that part only; it would not require a master worker at each step of production. Though he was late delivering the product (for which I nominate him as patron saint of programmers), his method was so clearly superior that he won another contract for fifteen thousand rifles. With his system perfected, he delivered these in under two years.

Whitney's method solved the "rifle crisis", transforming rifle making from a craft to an industry. By creating a method that made use of workers at all skill levels (rather than relying on individual masters of their craft), Whitney created an archetype for production. The lesson was not lost on the young nation.

And what of our own "software crisis"? We live in a time where the ability to quickly produce quality software may be the crucial factor in a business' long-term success. And in software, as with most things, quality is defined by the ultimate user of the product. As developers, we work very hard to achieve that. ColdFusion's success traces how much speed and simplicity matter. Yet, we still lack a methodology that helps us work together to tackle a problem. Programming is still very much a solitary art. While there is an important part for the lone coder, large-scale problems are often best solved by a team approach.

The Fusebox architecture encourages the creation of many fuses--small code files, each greatly limited in scope and having a distinct purpose. This means that the coder who works on a particular file doesn't have to know the overall application architecture--or even know of the existence of other fuses. Different fuses can be parsed out to different programmers with different skills; we don't require a few master programmers to handle all ingredients of the job. We're getting very close here to Whitney's mass production techniques.

Some developers are not comfortable with this idea. Not too long ago, I spoke with the owner of a large ColdFusion development shop and asked him what methodology they were using. He laughed, "We've got a great methodology--and as soon as I figure out what it is, I'm going to write it down!" Yet not having a methodology is to have a methodology--though I suspect it is one that few of us would choose if we were aware of our decision.

Then there is the reaction of a good friend of mine who, after hearing me talk on Fusebox and apparently inspired by the movie "Blazing Saddles", declared "We don't need no stinkin' fuses!" Many programmers feel secure working in an area where their hard work and skill have made them essential. Well, the good news is that job security isn't likely to be an issue for a long, long time. In fact, working in a system that produces on-time, high quality code is likely to enhance our fortunes even more. And do you really want to have to recreate the same code over and over--or notch one more user input form on your programming belt? Maybe having some help in these areas wouldn't be so threatening after all.

Fusebox can also help us in is dealing with documentation. We've been preached at--warned of the dangers of neglecting the dreaded "D" word since we wrote our first "Hello world!" program. But no one has told us how to document code. It tilts from the trivial ("Loop over all the users") to the tedious ("This next bit of code will ask the user for their name and password. The user will enter..."). In both cases, the documentation gets in our way more than it helps and informs us.

Fusedoc is a method for writing just the right amount and the right type of comments in our code. An experienced Fusebox architect can decompose an application into its component fuses and then, using the Fusedoc method, s/he adds the the information the fuse coder needs to carry out their job. The fuse coder receives a "fuse stub", a page template with the Fusedoc portion filled in. Fuse stubs minimize misunderstanding and confusion.

Using a fuse documentor (available at www.teamallaire.com/hal), you can run code that will automatically extract fuse information from an entire directory of fuses. Being able to quickly understand what code files are up to is extremely helpful in integrating code, and may help us begin to create reusable components. The fuse documentor is an example of inventing tools to help us create a complete development system--just as Eli Whitney invented the milling machine to make his system of standardized components work. As more of us adopt Fusebox, I believe we will see many more such tools created that will help us all.

Why is Fusebox important? By offering a method that allows each of us, at whatever skill level we are, to contribute to making high quality software, Fusebox provides a way that applications can be built in an environment where development cycles are short, complexity high, and resources limited. By breaking down a complex application into small, discrete chunks that do not depend on other pieces, companies can use less experienced programmers to handle the 80% of development that doesn't require highly specialized skills. If software development is to move from the state that rifle making was in two centuries ago, we will need to learn from Whitney's experience.