Visual Studio 2010 Beta 1 on Virtual PC

For those of you keeping track, Microsoft released the new Visual Studio 2010 beta 1 release last week.  I was a little disappointed – though not surprised – that, unlike with their September CTP,  Microsoft did not provide a Virtual PC image for the Beta 1 release.

Visual Studio logo

Like some of you out there, I prefer to show a little restraint when it comes to installing beta software on my personal machine.  I prefer not to hose my computer intentionally, nor incur the wrath of my better half by denying her access to her e-mail and internet.

Fortunately, the people at Channel 9 care about marital bliss, and have therefore posted a step-by-step video guide explaining how to set up your ownVirtual PC – at no cost! The video shows you how to install Visual Studio Team Suite 2010 beta 1, TFS 2010 beta 1, and SQL Server 2008 running on Windows Server 2008.  You don’t need an MSDN subscription to get this software, which means that some of it is going to be trial-based. But, it’s a great way to give the beta a test-run without risking detriment to your own PC.

My install was very straightforward, with the help of the video .  It took me about 3 hours from start to finish, mostly waiting for installation progress bars to fill up. Performance will vary based on your internet connection (when downloading the various software), and how much CPU and memory you are able to allocate to the Virtual PC. Oh, and the finished .VHD file will likely weigh in at a hefty 15 GB, so make sure to account for that ahead of time.

Have fun!

When to Check-In Source Code Changes

For the last couple of months, I’ve been leading an adoption effort at work to migrate developers away from our current version control system over to Microsoft’s Team Foundation Server.  During this time, I’ve been approached with a number of questions regarding best practices around source control usage, causing me to brush up on my own level of knowledge on the subject.

Recently, I was asked the following question:  When should I check in source code that I’m working on? At first, this seemed like a trivial question. But, since I didn’t have a good immediate response at the time, I figured it can’t be all that trivial.

So, upon further reflection – and consultation with several fellow developers – I’ve compiled the following list to be good situations in which committing changes to source control is a good idea.

You should check in files…

  • When the project is first created
  • When a new feature has been written (such as implementing a class, a method or a “slice” of functionality – from the GUI down through data access layer)
  • Before refactoring or re-designing a component (so that there is something to compare with, or roll back to)
  • When a bug has been fixed.

In what other situations would it make sense to check in files to source control?

MSDN Article: Using XML Comments

The May 2009 MSDN Magazine has a good article reviewing XML comments and their usefulness for code development and documentation.  The article is primarily written for VB developers, but the concepts do apply to C# developers as well.

I’ve been using XML comments since Visual Studio 2005 came out.  For your VB developers still developing legacy .NET 1.1 / VS 2003 apps, you can install the VBCommenter add-in, which will give you some of the basic functionality (C# developers have this out-of-the-box).

If you’re not familiar with XML comments – or if you’ve heard of them, but haven’t tried them out yet – give the article a look.

A New Look

I decided to go with a new look to the site today.  The old theme I was using was two years old, and had too much blue in it.  It also didn’t take advantage of a lot of the widget features available in newer versions of WordPress.  So, it is time for a refresh.

Hope you like it.

Pay Down your Technical Debt

I work in a financial company, so this analogy is especially poignant to those I work with.

We all know – or hopefully should know – the risks associated with being in financial debt.  At times, it makes sense to go into a little debt to buy something we can’t yet afford out of pocket (like a house or a car).  If we get into too much debt though, we end up paying all of our money in interest and don’t have enough to pay down the principal. Eventually, we may default or go bankrupt.

The same idea can be applied within IT.  Ward Cunningham coined the term Technical Debt to refer to instances where a developer chooses a poor design over a more well-crafted, sometimes “more expensive” design (in terms of time and/or effort).  At times this make sense – such as if we want to get something out to production sooner to take advantage of new features.

However, just like financial debt, we will continue to incur interest in those poor design choices even after that project goes to production.  This type of interest can come in the form of:
  • Larger maintenance effort
  • More difficulty in building upon the initial design
  • Having to perform manual operations that could have been automated.

It’s important to identify these risks and be sure to pay down the “principal” (through refactoring and re-designs) over time so that we don’t bury ourselves in too much of our own technical debt.  And, just like when paying down financial debt, it’s ok to pay down a little at a time (through small design changes/refactorings) instead of trying to make one big “payment”.

Think about any projects or systems you have on your team.  Are you incurring any technical debt from those systems?  Is that “interest” hindering your daily activities?  In what ways could you try to pay down that debt today, if you had the time?

Some food for thought…

White House – Open for Questions

Ok, I need to go rogue here for a minute…

Have you seen the latest technological experiment the Obama administration is trying this week?  When I first saw this, I was strangely excited.  I’m not usually big on politics, but I’ve got to admit that I’m impressed by how much the Obama administration is reaching out to the public for input.  It’s becoming increasingly harder to be apathetic about the direction this country is going — and that’s a good thing!

So, have you asked your question yet?