Always try one new thing but not two.

I've got a software related creed that I've managed to adhere to for several years now and, in my opinion it has been largely responsible for keeping me out of harms way; it's a simple creed and it goes something like this:

Always try one new thing but not two.

I need this creed because of my aversion to risk. Basically, without it, I'd probably never try anything new; Textboxes and Buttons - that'd be me! So, from one point of view it ensures that I manage to find new ways to do things but, from a more important standpoint it ensures that I can never get too far out of my depth. I've seen many projects fail - based on time, money or quality measurements - because the person or people managing the project couldn't stabilize a codebase because of too many unknowns. This has been very apparent since I stepped into the ".NET World" - bigger tools, bigger mistakes.

For me, the creed ensures that my bag-of-tricks is always kept fresh by cycling in new, good stuff for old, tired stuff. This is basically how I managed to teach myself Server Controls, ADO.NET, C#, and a whole host of other goodies - by attempting one on each new project. Thankfully I could now happily architect a WebForms project in C# which made extensive use of Server Controls and had some nifty ADO.NET trickery without a great deal of risk.

On my current test project - An ASP.NET ContextMenu Server Control - I decided that the new thing would be that I'd build my first server control using VB.NET. This was good in that I "think" much more clearly in VB.NET but, I love developing server controls using C# because of its native support for XmlComments; they makes it a cinch to easily generate professional looking .chm documentation with very little additional effort. VB.NET on the other hand does not yet have native support for XmlComment syntax which means that I would be reliant upon third-party tools to help me get the job done. Not a huge risk, but my biggest risk nonetheless!

So, today I did a bit of research and came across the "VBCommenter PowerToy Development" workspace on GotDotNet.com. I downloaded and installed the tool (it's a Visual Studio .NET add-in) and fired up my server control project. After installing the tool I noticed that the add-in had successfully added itself to my VS environment. Clicking on the VBCommenter option displayed the uncomplicated UI for configuring the tool:

The tool only offered 3 syntax choices (none of them being my preferred option) and also affords the ability to enable a macro which interactively inserts XmlComment skeletons as I type (this is the option labelled: "Insert Xml comments in source"). I selected '@ as my preferred syntax and gave it a trial run - I typed '@ <ENTER> into my code module and PRESTO! The following comment block appeared before my very eyes:

'@ -----------------------------------------------------------------------------
'@ Project  : ContextMenu
'@ Class  : WebControls.ContextMenuItemCollection
'@ 
'@ -----------------------------------------------------------------------------
'@ <summary>
'@ 
'@ </summary>
'@ <remarks>
'@ </remarks>
'@ <history>
'@  [Darren Neimke] 10/02/2004 Created
'@ </history>
'@ -----------------------------------------------------------------------------

That's a pretty good start... different syntax but, same result as my trusty C# editor gives me. Based on the fact that I had ticked the "Create Xml files when projects are built option" I decided to press forward and pump out my first Xml file. I pressed BUILD and raced off to the filesystem to see my Xml file. Disappointment! There was a file created but, alas, it contained nothing but a root element (even though I had continued on and added comments to all of my methods and properties).

The documentation which comes with the VBCommenter is scant (to say the least) so, it looks like being slow progress from here as I attempt to make ends meet.

In a nutshell, it's good to try new things because it forces you to learn new ways to go about solving problems and also ensures that you have the possibility of improvement - but, be aware that trying new stuff can also increase your risk of not being able to meet your deadlines and that's why it's good to limit the number of new things that you are attempting at any given point in time.