Yet another lost art, the functional specification. Many large development firms require months of functional specifications and round table reviews before going live with a project. Why? Perhaps, to throw “red tape” at a problem when you could be coding the solution right this instant?

There is something these big companies have learned which many folks miss time and time again, designs lead to stable products. Should you still write a software design for a one person project? Of course! The depth of design may not be as great as a six man project run by a company like Cisco Systems but a design does matter.

There are plenty of sites you can visit that show “piss poor planning.” Some sites lack vision and scalability because they didn’t think ahead. Here is a question:

When you drive a car do you look straight down over the hood or do you look ahead on the roadway?

You look ahead! Those that do not tend to swerve a great deal and cause mass hysteria on the roads. Do all people look ahead when driving? Heck no! But they should; it leads to a smoother ride with less accidents.

You can apply this logic to any type of coding or web design. Don’t think “what can I do now?” think “how can I plan for success?” Developing a web application can be done by a single developer at a PC with no clear vision but a an awesome concept that can bring much success.

What happens if people like your project? When a big named tech head (i.e Leo Laporte) jumps on your product bandwagon and within minutes you find flash crowds of people slamming your site, hammering your code and the system falls under the weight of a million tiny keyboards.

You didn’t plan ahead.

You think “I’ll optimize this later” and before you know it, you have four thousand lines of code and you don’t recall exactly what needed to be optimized. When will you find out? When your site is live and you’re knee deep in user e-mails with obscure error messages telling you things are “broke.” Don’t wait to optimize your database transaction from five queries to one until the site is “stable” - do it now, while you remember.

A great example is myspace.com. Everyone knows the site is horrible. It is aged, lacks any new features, generates thousands of random errors while you’re browsing and requires a masters degree to customize the layout. Why? More than likely because success came fast and furious before the site was ready to handle the population. Probably a result of bad planning.

Now, like a house of cards, it balances on the edge of destruction on each and every click of the mouse. Falling under its own weight the site remains popular but featureless and frustrating.

A formal design process will give you new ideas, allow for features you didn’t think of and raise concerns about edge conditions, scalability and an overall user experience.

You may simply bullet out a few thoughts on your set of features, list out features you’d like but know will take more time (i.e a “feature list”). You can then weight the features you want against those you need and break them down into chapters in your specification.

Now, in each feature “chapter” you can break out what the feature will do, how it will work and some ideas on how it may be implemented. Diagrams are optional but pictures are worth a thousand words. As you write you’ll have a few Epiphanies, a few great ideas that just need to be implemented! But without writing you’d never had thought of them, or worse… you would have thought of them after you’ve written 1,000 lines of code which is too strict to fit them in without causing major regressions and instabilities.

The idea of a functional specification works out design issues and raises new issues you have yet to think about. You’ll have a formal list of features, concerns and “oh oh” problems before you know it. With that you can begin to think about how you’ll code through some of these trials, how you’ll scale certain situations and best of all, you’ll have hit many major hurtles before tying yourself down to thousands of lines of code.

Nobody likes to get halfway through a project and think “oh oh” because you’ve forgot a major feature that just won’t fit the project you started on a whim.

The human brain is capable of remembering thousands of details, millions of individual events and still have 80% free for useless fun. However, nobody said you will be able to recall it all on a moments notice or think through every technical detail like a chess game of code.

Think ahead, write it down, work out the details and then code. Large corporations do this and have seen tremendious success using the concept. As you grow you’ll find documentation is a huge part of your success and an audit trail to your failures.