As an idea person, sometimes I find it difficult to take that first step and start implementing something I have envisioned.  This week, as part of the Knight-Mozilla Learning Lab, I attended two online lectures which gave me some new motivation for getting started and some concrete advice for the earliest stages of the implementation process.

Even before attending these lectures, I've read a lot about getting to a "Minimum Viable Product" and releasing early, "iterating" (getting user feedback often in the development process and using it to guide your progress), and "dogfooding" (using your product on a day-to-day basis as you build it) when possible.  I was already a believer in these principles of rapid software development, but the lectures this week added another dimension to some of these principles.

Here are some of the key ideas for starting new projects and ramping them up quickly:

Figure out if you want other programmers' help and how to get it.

You probably want outside help.  Working on something is easier if you know there are others motivated by the same vision.  Technical problems are easier if there are other smart people to talk them over with.  And if you want the help of others, you have to find a way to communicate your vision to them.  Here are some common ways to do that:

• Written description
• Graphical mockup
• Online video
• Working prototype

The latter ones are more work, but can be much more engaging and much more useful in garnering support for your project.

Constrain yourself to do a prototype in one day, start to finish.

The first payoff for a new project is when others see how great your idea is, and getting your prototype done as soon as possible will shorten the waiting time before this payoff.  Getting it done in one day forces you to distill your idea down to one or two key ideas, and often you will surprise yourself at how simple a first implementation can be.

Knowing that you're only giving yourself one day to complete your prototype will also help you find creative solutions to any problems you find.  Give up quickly when you hit a wall and find a way around it, instead of through it.

For a mockup or a demo, visual design can be "borrowed".

Many programmers feel like they can't do graphical design very well.  The answer to that is to do whatever it takes to get your prototype done as fast as possible, including using someone else's design.  "Good artists copy and great artists steal," as they say.