On a fairly regular basis, I get email or blog comments where someone will ask me how to create something they have zero experience with. Invariably, it's a project that is enormously complex.

Poking a little fun (good naturedly, I'll add) the requests are usually something like this:

Hi.

I want to build the next space shuttle. I know how to build landing gear and the fuel injection nozzle for rocket engines, but otherwise have no idea. Can you help?

or

Hi

I'm really excited about learning GoldenSuperInversionSharpLight.NETXP (with MEF) and have decided to write <incredibly complex app>. I've already set up the codeplex/github/whatever site for it, but don't know where to start. Can you send me some code?

I'm actually cool with requests like that, as long as I am able to teach the person to fish and don't become their personal fishmonger :) I like to see people starting out with new technology, and I'm always happy when it's a technology I enjoy or believe in. Chances are, though, I won't send you the code unless it is something discrete I can put up as content, or something I just happen to have sitting around.

You have to decide if you're interested in the learning that comes out of it, or with actually completing the stated goal. The approach will be slightly different in each case. In the former, you'll just build a bunch of prototypes. In the latter, you'll learn from those prototypes and build a real app.  Ultimately, though, I think this comes down to treating your pet projects more like real projects.

Here's how I usually recommend these folks tackle the problem.

1. Find out if someone else has already done it

You may want to do it anyway, but always check to see if someone else has solved this problem before you. At the least, you may be able to learn from their approach or source. Few things can stop a project in its tracks like learning halfway-through that someone else has already done it.

When searching around, be multi-lingual; just because you're working in C# doesn't mean you can't learn from something someone did in Ruby or C++.

2. List what you know and can build on

You've picked this pet project presumably because you have some knowledge in the area, even if only a little. Figure out exactly what you know about the problem domain and the technologies involved. List that so you can get an idea of the percentage of new learning you'll need to do to build the application, and also as a reality check to yourself.

3. List what you don't know

Next, start doing some research to figure out what you don't know. Using the Space Shuttle example above, perhaps you know how to build propulsion systems, but have no idea how to build a structurally sound wing, or cockpit. You don't know how to build the command and control systems, and there's that issue with heat shielding. Oh, and life-support - can't forget that.

Figuring out what you don't know is the difficult part. It's an iterative process where each thing you don't know will lead to other areas you don't know. That's ok; it's what you want to have happen.

Do lots of searching to find out what others know about the problem domain or technology. Expand your searches based on keywords you find in the search, and document what you do find. If you run across similar apps, snag any screen shots and save their web page descriptions in a folder. If there's source, grab a local copy and note the URL.

4. Figure out what the app needs to do

Too often, we focus on just the technical aspect. What will hold you up, though, is the problem domain. Taking information from #1, 2 and 3 above, document (bullets are usually fine, kanban-style boards are great) the requirements for your application at a level that is useful to you. Be your own customer. Then, when you get stuck on something, you can go back to this list and work on something else. Always be willing to revise this list.

5. Evaluate the application

Is this really the application you want to build? Make sure you're not biting off too much. If you can break it up into small functional units, that's great, but you may still be committing yourself to a six month development effort; more than most people can follow-through with.

If the app turns out to be too large, maybe there something similar in the same space? Let's say the space shuttle is too much work; but maybe you could work on building a two-seater airplane? (or an RC airplane, model rocket...or paper airplane)

6. Prototype what you don't know

Never start a big project with significant unknowns by doing File->New Project and starting the real application.

I've always found that prototyping unknown or risky areas is the way to go. The prototype is stand-alone, ugly, and meant to be thrown away. You will be tempted to put other application requirements into the prototype, but don't. It should be used to prove out a single thing. You can copy/paste/refactor parts of that code into the solution you eventually create, but it should be external to that solution.

Back when I worked for a living (joke just for my consultant friends, TYVM), PMs and customers would often want to turn a prototype into the actual app. The words "throw away" always raised hackles. However, that's how we learn. Without throw-away prototypes, application code would be a mess of crap that follows our own individual learning paths more than any real requirements or sound engineering practices. Yeah, I know.. some of it is.

Prototype code typically does not follow best practices and has little to know real recognizable patterns. Unless you're prototyping the pattern itself, that code just belongs in the final app, not the prototypes.

7. Seek help from the community

Find the communities that exist around the areas you're prototyping. While no community may exist for "People who build space shuttles", you may find great communities of folks who build rocket engines, and others who build control systems, and even more than can deal with building components that hold up in a vacuum.

Present those communities with discrete problems, and seek help. You'll likely do better than if you ask a large, unfocused question like "how do I build the Shuttle". Instead, ask how to go about making it so a fuel nozzle atomizes exactly 15 cubic cm of fuel per second, or at least ask how fuel atomization works.

When you solve a problem the community helped with (or tried to help with), go back and provide the answer to the community. IMHO, you owe them some closure and something to add to the communal knowledge pool, even if you never visit the forum/site again.

8. Add a module to your application

If you've decided you're doing this for more than the learning experience, you'll take what you've learned from the prototypes and the community, and add that into your application. As part of this step, architect as much of your solution as you know, and try and stay clean. Screw up the architecture? Refactor to clean it up and keep going. Don't be afraid to redo code.

9. Iterate

Iterate on this list. List more things that need R&D, prototype more bits, add more to the project etc. Just keep making baby steps that are small enough to accomplish, but large enough to give you a sense of satisfaction and a desire to continue on.

10. Set up an open source project

Once you have a project structure in place, and know how to do the majority of the work, you may want to set up an open source project and recruit folks to try and help you out. Don't do this unless you've done some real work on the project and are committed to seeing it through.

Keep in mind, that it's hard to get folks interested in an open source project. What you're doing has to be compelling and interesting. It has to be something other people will want to do. If you keep all the cool stuff for yourself, no one else will join up. If you succeed, though, it's awesome for the community and for you.

IMHO, one of the greatest things a developer can do is release their source to the community. Don't worry about something being too ugly (no one likes their own code, but many can learn from it), and certainly don't think your code or idea is so incredible that it's worth millions. Unless you have a strong, executable, in-place business plan, and real capital to do something meaningful with the bits, just release the source. The sense of satisfaction you'll get, and the good karma, are payment enough.

Speaking of which, I need to get the Silverlight 4 version of my C64 emulator up on Codeplex. :)