ScottW has an interesting new theory for prototyping:

if you cannot build an interesting working version of an application in less than 1000 lines of code, you are likely over complicating things.

I think he's actually talking about more than prototyping, but the idea is that if you can't get your idea off the ground quickly, then you've got a problem. And it's not that he's saying you can do anything in very little code. What he's actually advocating is leveraging third party libraries to get a lot of the functionality you need.

If you know me at all, you'll know I agree with this completely. Leveraging other people's work is key to quick software development. The less code you have to write, the less you have to maintain. Yes, there's the risk that the software you are using will have an issue and you won't get it fixed, or that it won't do exactly what you want, but getting 80% of the way there is better than nothing, right?

It's the classic argument of "Buy vs. Build" and "Not Invented Here". If you believe that no one can solve your exact problem, then you're going to have trouble following Scott's guidelines, and in the long run, your development costs will be a lot higher than they should be. By relying on the expertise of others, you can get a lot done in a short amount of time, and you're left with less code to maintain down the line.

I've got a few pet projects that I've wanted to get going. I think I'll give this guideline a try to get them off the ground.