Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

Creating Awesome Applications when you're Clueless

Pete Brown - 06 April 2010

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:


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 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. :)

posted by Pete Brown on Tuesday, April 6, 2010
filed under:        

17 comments for “Creating Awesome Applications when you're Clueless”

  1. Ahmedsays:
    Well done Pete. Thanks a lot for those wonderful tops and help.
    Right now i'm thinking of new cool idea, but can't start on it now because i'm new developer. Brand new. have 0 experience in C# (which i am aiming to learn + Sliverlight).

    So my question to you, how new developer have no experience can start learn technology and the can apply that to their project? Or learn while they are working on their project?

    When i can start to learn, land my first step and get good knowledge of eg: C#, Slivelight, so i can start work on my project but in short time?

    Some guys said, personal courses, others said, online video training or book, ....etc...

    What it your recommendations for new developer like me.
  2. Petesays:


    If you have no C# experience, I'd start there. The language is the most important thing. Pick up a good C# book and work through the examples, most of which will be console apps or Windows Forms.

    Once you have a good grasp of the language, then go visit http://silverlight.net and start working through some of the beginning videos and tutorials. Tim and Jesse have put some great beginner content up there.

    That should get you through at a pace about as quickly as you can go give that you don't have any programming experience yet.

  3. Ahmedsays:
    Thanks Pete I appreciate your advices. I'll start look for a book about c#.
    If you have any recommendation about specific book you thing it's good and can move me from step one/beginner to advanced, that would be great.
  4. Petesays:
    I don't have a book recommendation, but try and get one that covers .NET 4. Books are a very personal choice; what works for me probably won't be the same that works for you. That said, many of these look promising.


    The "in a nutshell" book looks good, as does "Introducing .NET 4.0 with Visual Studio 2010"

    My own Silverlight 4 book will be out this summer (you can get early access to chapters as they are released at http://manning.com/pbrown) However, I assume you already know C#.
  5. Jacco Rademakersays:
    Thanks for writing these steps this clearly. With some minor adjustments this article is also applicable to tackling client requests.

    I might start learning rocket science... Since I know the language the books are written in, nothing should be holding me back. ;-)
  6. Khalilsays:
    Nice article even though I try not to build things I am clueless about. Anway, I spotted what may be a typo in the statement "and try and say clean". I guess what you meant to say is "and try and stay clean"?
  7. Christophersays:

    Before running out and spending $40 to $65 on a really boring 500+ page techno bible, consider the myriad free samples and examples and tutorials on the web. There are free compilers for every language you could possibly want to write in. Everything you need to be writing code in the next 30 minutes is available on the web.
    Just google "free X compiler", and "X Hello World Tutorial" where X is the language of your choice Once you've installed your compiler of choice, written your first "Hello World" app and maybe a few other simple examples, you'll likely have a better idea of whether or not you like development enough to get to the really complex projects.
  8. AbdouMoumensays:

    kanban boards are a method of monitoring the project's status and the flow of tasks in the different development stages.

Comment on this Post

Remember me