Plain-spoken Online Conversion Rate Newsletter - covering web design, sales, marketing, copywriting, usability, SEO, relationship marketing and consumer psychology.
Don’t Blow Your Fuse(box)
You've thoroughly planned the purpose of every page and identified every dynamic link in your website (Wireframe Yourself ). You've elaborated all the design and content features (Behind the Scenes) and have created templates of how the finished product will actually work ((Proto)Type-Cast Yourself! ). Now it's time to hand your baby over to the folks who are going to develop your applications. How do you start?
You've got my sympathy - bet you think you're about to navigate a minefield and somebody forgot to give you a map! So I've asked my pal John Quarto-vonTivadar, strategic planner extraordinaire and co-author with Hal Helms of Code Rutters: Discovering Fusebox to help you understand how developers work. When it comes to this stuff, he's the "horse's mouth!" Is he biased? Yep. He wants to make your job (and his job, truth be told) easier, faster and cheaper! He's a big believer in an open development methodology, and I'd like him to tell you why …
When it comes to assembling the actual programming architecture of your website, development teams use one of 4 methodologies:
No Methodology. What gets done and how it gets accomplished depends on the experience and skill of which ever team member is working on it at the moment. If development is analogous to constructing a house, the No Methodology approach is like letting the construction crew work on stuff any way they want. While that might work for re-painting the rec room, who wants to be standing on the 25th floor of a building built this way? It's the start-each-project-from-scratch approach, trouble-shooting problems as they arise, and it works as well as any other approach for small projects (up to the point where it stops working, typically at 3am, and the desperate search for something - anything - that will bring the project back on track begins).
Because projects are handled as they come in and there is typically no organizational strategy to guide the implement of projects, the No Methodology approach spells disaster for project maintenance, which can account for up to 80% of a project’s cost. If you do things differently every time, the odds you'll remember how you did something six months later are slim to none.
Best Developers Method. Get the best developers you can (at whatever cost) then step aside and let them do whatever they want. What you essentially get is a bunch of lone-star gunmen in cowboy hats sitting in their cubicles typing out code and the mysteries of the universe. But if 70% of all software projects fail, then the Best Developers Methodology means that even when you have the best talent, you still risk a 7-in-10 failure rate. The problem is this: "Best Developers” do not necessarily equate with “best practices.” It can feel pretty defeating when you hire the best (who are purportedly at the cutting edge of their field) and conclude with a failure.
“Secret” Methodology. There is a methodology here (usually), but its proprietary. Remember the quote from Top Gun, “I could tell you but then I’d have to kill you” ? In this case, the problem isn't with the success of the methodology itself, it lies in the costs: a development house with a proprietary methodology has to invest capital getting new developers up to speed. Guess where they recoup that investment.
When it comes to handling ensuing versions (the part where you spend 80% of the project's cost), you are constrained to stay with these developers - after all, they are the only ones who understand the secret techniques. They can afford to produce a lower-profit first version, nodding sagely as they speak of recently uncovered secrets known only to Ancient Babylonians - and very often they do deliver a phenomenal debut, fully aware they’ve got a monopoly on the other 4/5th of your project budget. This game has a name! (Hint: there's a space called "Boardwalk," and it's the most expensive square on the game board.)
Open Methodology. This approach is based on a publicly-known, standard set of processes, and the benefits to developers and clients are significant. Developers know learning these techniques is an investment in their own futures, as they are employable at any development house using the same open standards. The development business model benefits too: since there are known standards, the development house needn't invest in teaching the process to new members. With a supply of educated talent available, a development house can expand staff to suit its scale and handle more projects. It can also quickly leverage any investment in tools it develops to match the open standard, saving time and money.
These advantages spell good things for you. You can accurately judge the bids for your project. And you aren't tied to one development team for subsequent versions - any team employing the open methodology can bid competitively and understand the work that has been done to date. You save precious time and money!
One of the most exciting Open Methodologies is called Fusebox, widely popular with development houses because its techniques, although originally developed for ColdFusion, can be applied easily to ASP, PHP, JSP, or any development language of your choice.
Fusebox employs three critical principles:
Modularity. A project is divided into small component pieces, each tightly defined. In Fusebox these are called “fuses,” and related fuses are grouped together in “circuits.” Because it’s modular, difference pieces can be distributed to different groups.
Severability. Each fuse is self-contained - the fuse, the whole fuse and nothing but the fuse. References to other fuses are set as variables. If those references change, the fuse in question doesn't have to be modified.
For example: Imagine you are coding highway exits: Exit 64, Harry's Diner and Devil's Canyon State Park. If you code these into every related fuse and the highway exits get renumbered, or Harry's closes down or Devil's Canyon goes condo, then you have to remember every place they appear in your code so you can update them. But suppose you assigned variables instead of specifics to every fuse ahead of time?
onTargetExit = "Exit 64"
onHunger = "Harry's Diner"
onSiteFeature = "Devil's Canyon State Park"
Your fuse references the variable and accesses the "value." So when Harry sells out to McDonalds, you simply redefine the specific
onHunger = "McDonalds"
and it is passed along to every fuse using that reference. You don't have to track down or remember a thing!
Because modules are severable, developers can construct each simultaneously without worrying the work will conflict with something somewhere else in the code.
Clarity. "Fusedocs" are structured comments that document the interface between modules (“fuses” and “circuits”). They are so popular and clear that I see people using Fusedocs even when they aren't using Fusebox! With this defining clarity at hand, each team working on a modular piece knows exactly how that piece will interact with others.
These principles give Fusebox the power and flexibility to allow for fast development. You get a series of code that can be dropped into place and works seamlessly - and no module had to be built in conjunction with any other modular piece. The end result is a tremendous savings in time and money - and sanity.
Well worth thinking about, partners in ebusiness! To learn more, point your mouse in the direction of www.fusebox.org, where you can download and view examples and demo applications. Just when your plan starts coming together, there's no reason to blow a fuse, is there?
We will never give, lease or sell your personal information. Period!
We strive to only send e-mail to those who want to receive it.