At Software Architects, when I’m not on a project, I am encouraged to seek certifications.  These certifications help their partnership with Microsoft and they help us build our résumés.  Since my hire date of Febuary 1st, I have completed:

• Microsoft Certified Professional
• Microsoft Certified Application Developer
• Microsoft Certified Solution Developer
• Microsoft Certified Technology Specialist (new 2.0 exams)

I probably would not have sought getting certified if my employer hadn’t paid for it, but I’m glad I did. 

Note:  the following is my personal view of the Microsoft Certification process.  I have not taken any Sun/Cisco/A+/or PMP exams, so I’m not sure how they stack up.

Certifications alone will not take you very far.  They do not show that you know how to utilize a particular technology.  They do not show that you have ANY experience in a particular technology.  I’d also dare to say that they can be obtained only by studying tests, not actual concepts. 

But, combine them with significant experience building software, and you have solid evidence that a particular person not only knows the technology, but also knows how to apply it on real software. 

If I were reviewing résumés, I wouldn’t put very much weight in the fact that someone has certifications.  If that was ALL that they had, I’d consider it negatively.  The only certification I would really put stock into is the Microsoft Certified Architect, where you are presented a problem, and you have to submit your architecture to a panel of well-known, high-echelon developers for review.  The only downside is that it costs $10,000.  I don’t think my employer will be paying for that any time soon…

I read Joel Spolsky religiously.  His posts are few-and-far-between, but the SNR (signal to noise ratio) is seriously high.  His posts are worth waiting for because there is so much meat.

Anyway, since he frequently posts interesting articles, why am I blogging about this one?  This one really hits the nail on the head with me, that’s why.

http://www.joelonsoftware.com/items/2006/04/11.html

Programmers are good at programming.  The time they spend learning tasks extraneous to their day-to-day skills is time not improving the developmental skills.  I believe in being multi-faceted, but your developers shouldn’t also be your system administrators.  Your developers shouldn’t spend time assembling desks or ordering/building computers.  Taking your developers off of their high priority tasks to do phone tech support is a waste of his/her time.  High morale and few distractions will lead to better software in the end.

I don’t normally like to blog about a blog, but this post is worth reading.  Go.  Now.  Read it.

Now playing: Breaking Benjamin - Natural Life

A lot of times when starting a new project you get fairly far into coding before realizing that you might need tools like source control or a flexible build system.

This article will outline what is sometimes called “Iteration Zero,” which is the step in which you setup your development environment. 

Keep in mind that these are just suggestions (by me) for a healthy project environment, not a cure-all for development.  Each team will (should) have a unified process that everyone agrees on.  Hap-hazard development with little support for teams can put a burden on your developers and put the project in jeopardy.

Step 1:  Choose a source control provider

Even when doing pet-project and single-man projects, you need source control.  Let me repeat this.  You need source control.  There are many to choose from, and they are generally easy to use.  I personally use Subversion.  It is free, comes with a ton of features, and is easily used through the right-click explorer icons.  I would warn against Visual SourceSafe for large projects, but for smaller projects it’s not that bad and is tightly integrated with Visual Studio.  I’d recommend Subversion (or SVN for short), CVS, or Perforce (which is not free).  This article will focus on SVN, since it is what I use most.

I typically create a sandbox folder, where all projects under source control reside.  Here’s a look at my current sandbox:

As you can see here, I have about 5 projects, with various icons on the folders indicating their status.  This is provided through TortoiseSVN, an explorer shell add-in.  TortoiseSVN adds these context menu items you can see here where I right-clicked on the screen.  From here I can checkout projects that reside in the subversion repository.

On projects with distributed teams, you can install Apache and use a WebDAV module to allow HTTP access to the repository.  As long as you use SSL and a password file, you’ll be secure.  There is a free online book available here that has some good information on how to set this up.

So I’m going to navigate to my subversion folder (NOT my sandbox) and create a new repository for our sample project.  Let’s call it FinanceAssistant.  First, we have to create the directory that will hold the repository.  Next, I right-click on our new folder and select “Create Repository Here.” 

 Here you have a choice between a Native File System and a Berkeley database.  I have heard that there are no real advantages to using a BDB, though there are some constraints.  Just about everyone suggests using a Native File System repository.  Once this is complete, your repository is ready for checkouts.

The next thing I suggest is to create three folders:

/trunk/
/tags/
/branches/

This is a crucial step in effectively utilizing the power of a source control provider. Basically all of your development goes underneath the trunk folder. When you think you are ready for a first-release to your customers, you can Tag the release, which will basically take a snapshot of the current state of the project and stick it into a folder underneath the tags directory. If any bugs are found in the tag release, then they are fixed and merged back into the trunk so future versions get the fix. If any experimental development goes on (like upgrading to a new 3rd party dll version, or some major re-work or refactoring) then you can branch the project. This avoids the problem of having one developers experimentation negatively affect the entire team. Here's how our project might look:

/branches

     /ExperimentalBranch1


/tags

     /0.4

     /0.64

     /0.85

     /1.0

     /1.4


/trunk

    /src

What's great about this approach is that you can, at any time, checkout a specific version of your project that may have been in the past. Everything that was included in source control will return to the state it was in at the revision you specify. This can really help at times, especially if you have customers using old or different versions of your software and are reporting bugs.  The first step is to create the three base directories.  Let’s do this via the Repository Browser in TortoiseSVN.  Right-click anywhere in explorer and go to TortoiseSVN->Repo-Browser.  Enter in the path to your repository, which in my case will be this:  file:///e:/svn/FinanceAssistant/ (notice the unix/web style path)

. From here I can create the folders that I talked about. Once I have them created, I am ready to check out the trunk to start developing. You definitely don't want to have this entire structure checked out at once. You might inadvertently modify a file that isn't under active development.

I’ll now go to my sandbox folder and checkout the project by right-clicking explorer.  Notice how I’m checkout out the trunk subdirectory, not the root of the repository.

There are many options to choose from while checking out a project.  Here I can choose a specific revision # to checkout from.  This is good if a developer checks in some breaking changes and you need to roll-back to a revision that was working.

This will create the working folder in our sandbox.  You’ll notice that any directory under source control will have a hidden folder called “.svn”.  The period in front of the svn wreaks havoc with FrontPage Server Extensions with Visual Studio 2003.  ASP.NET 1.1 projects will need to look for a specific version of TortoiseSVN that uses a “_svn” directory instead.  For Visual Studio 2005 we don’t have this problem.

So now we have our working folder, ready for development.  After we make changes to the contents of this folder, we must Commit the changes.  When we want to get the latest changes from the server, we Update our working copy.

So at the beginning of every day, we should Update our working copy to get the latest changes.  We then will make changes until they are stable and pass tests.  After this we Commit the changes so that other developers receive them.  It’s important not to let your project get too out-of-sync with the repository.  It is worse, however, to commit changes that break the build and prevent other developers from being productive.  If any two files are modified and checked in at the same time, subversion will do a simple merge and ask the developer to verify the changes using a Diff Viewer.

Using a source control system is a critical step that many small shops just don’t do.  The risks are enormous if a disk fails or if developers overwrite each other’s changes. 

Here are some more resources on using Subversion:

• The free ebook.  This was my first resource for using Subversion.  It is pretty concise and will answer many beginner questions.
• Pragmatic Version Control with Subversion by Mike Mason.  This book is a good complement to the free ebook.  It is short and has good examples in the book.
• TortoiseSVN.  My favorite SVN client.  It’s very easy to use and is updated pretty regularly.  It’s just like TortoiseCVS.
• AnkhSVN.  Visual Studio 2003 integration with SVN.  It works pretty well, but I still fall back on Tortoise for some tasks.  No support for Visual Studio 2005 yet.

In step 2, we’ll take a look at a slightly different project directory structure than you’re probably used to.  We’ll also talk about NAnt as a build tool to support this structure.  Until next time….