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
Poking a little fun (good naturedly, I'll add) the requests are
usually something like this:
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?
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
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
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
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.
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
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
Speaking of which, I need to get the Silverlight 4
version of my C64 emulator up on Codeplex. :)