Podcasts and Prototyping

Ron Jacobs recently published a podcast with me for his ARCast.net show (which is a free Podcast series aimed at architects).  In the podcast we covered a couple of topics people might find interesting:

  • Some of the history behind .NET and specifically ASP.NET
  • The importance of prototyping (and how not to screw it up)
  • The importance of developing "soft skills" to be a successful architect

The prototyping discussion is one that I think has a lot of relevance to many projects out there.  It is a best practice that I really encourage all developers to dedicate more time towards -- since done right it really allows you to experiment and quickly try out a lot of ideas and concepts that can help you dramatically move the innovation dial on your projects. 

The critical thing with prototyping is to ensure that you never, never, never allow prototype code to morph into becoming production code.  Don't try and "clean it up" or "refine" it to make the prototype code production grade.  This type of "clean up" rarely goes as far as it should, and usually ends up starting a project off on a very poor footing.  And checking in "quick and dirty" prototype code to an existing code-base is kind of like tossing in a bad apple into a barrel of good ones - you can easily end up with "code rot" spreading across a code-base this way.

It is always much better to simply start a blank new project and import the prototype concepts -- and not the code -- to the project.  Spend extra time up front ensuring that the new production code starts off at 100% production quality, and don't try and save a few days by re-using the lines of code in the prototype.  What you'll find after a prototyping exercise is that writing the "real" production code from scratch ends up going much faster than you might have expected, since the feature ideas are much more fleshed out in your head and consequently you'll have a much deeper understanding of how the implementation should be structured.  The code quality bar will also be dramatically higher.

I recently ran into this with one of the ideas I've been playing around with prototyping in my spare time the last few weekends.  I had some pretty complex dispatcher logic that I'd been working on and morphing overtime as I experimented with features and approaches.  I knew that once I'd finished playing around with some of the programming model ideas I'd be able to clean it up considerably - but it wasn't until last night when I set aside a few hours to write a new implementation from scratch that I was able to see just how dramatic an improvement I was able to get over the iteratively developed prototype one.  I suspect most people will see similar code improvement/quality results by being disciplined and making sure that they consciously throw-out prototype code once they've finished iterating/learning from it.

To listen to the podcast in full visit Ron's podcast link here.

Hope this helps,


P.S. I just saw that Paul Glavich also just posted another podcast with me here.  Show contents on this second podcast include: ASP.NET AJAX (aka Atlas), WPF/e, Windows Workflow/Cardspace, BLINQ and Script#, and Visual Studio 2005 SP1.  Definitely check it out too!


  • Scott,

    Very good advice. If you question this advice, pull up any project you did 2-3 years ago and have a look at the code. There's no doubt you'll be saying, "Why did I do it that way? I could do it much better now." I think that same idea translates what you've said regarding prototype code. Thanks as always.

  • I think the position about prototyping is too absolute.

    I find that there are times when evolutionary prototyping is called for and important to making sure that the result is buildable, operable, and (sort-of-) deployable at all times.

    That does not mean that refactoring won't happen, although I have found that interface contracts can be evolved alongside the effort too, usually without much change likely to the stable parts.

    I notice in a three step project I am conducting right now (Java JNI Bridge Native Win32 internal COM ODMA API), this was the only way I could ratchet up and stay sane.

    Oddly, inside the evolutionary spirals, I also do throw-away prototyping in the form of test fixtures and standalone uses of new modules until I am confident to integrate that new code into the bigger picture. (I actually don't throw them away, the test fixtures are available to turn into regression tests.)

  • yes, In fact if you look at the project 6 months back you will be able to tell yourself that these are the places I could have done better. and According to me these is the amount of improvement you had in the given time frame and if you do not feel any thing can be improved, well you have not improved your self with the advancement of time and technology

Comments have been disabled for this content.