Duh.

I have worked with Team System quite a bit and with alternatives just as much. With a lot of experience behind me on this, I feel confident I can make a legitimate case for using Team System in a small team.

I consider a small team a development organization of fewer than 10 people.

Some Context and Disclosure

• I am a Team System MVP
• I use Team System on a daily basis
• I use SVN+Team City on a daily basis
• I care more about pragmatism and craftsmanship than tooling, and that means focusing on how to use tools, not just the tools themselves
• I have been present on day one of a brand new team
• I have been in a team that has grown quickly over a short time

Focus on the Work

What happens when teams squabble about tools instead of just getting on with it? Lots of churn and wasted energy, is my experience.

I can report having seen small teams succeed and fail. The success or failure in both cases obviously has a lot more to do with leadership and business than developer tools, but I can also say the way companies approach developer tooling can have a lot to do with culture.

Any startup or small team simply must be focused to succeed. This can also be extremely difficult to achieve. A small team simply doesn’t have the capacity or depth to be distracted with issues not pertaining to delivering product. Paradoxically, team members are often wearing several hats. That is, everyone is doing a little of everything. That can quickly trend to entropy, because no one ends focusing on the work at hand.

The last thing I want to do on day 1 of a new team, or very often in a small teams, is visit tooling. Not deliberately making choices about tooling, though, will eventually bite you. Hard. How many of us are in organizations with over 2 brands of source control systems because new ones were added in an ad-hoc manor? I’ve been there. How many unit test frameworks are being used? I have been on a team that used 4 at once. Think that caused some problems?

As team lead, I care far less about optimizations of specific tools, and far more about a cohesive and fluid process enabling flow within the team. I care a great deal that there is a single source of truth for requirements and very little that we are using the coolest new unit test framework.

Often, focusing on work simply means implementing a system of tools and getting past the discussion. Have you ever heard developers purse fight over text editors? Now, there’s a constructive use of energy. The same thing can happen when geeks whip out their favorite source control, merge tools, unit testing frameworks, Visual Studio add-ins, logging library, laptop brand, or bug tracking system.

Point number one is let’s get past the time suck of the my-NAnt-is-better-than-your-MS-Build and just prescribe a toolset so we can get on with the real business of our team.

Team System is Like a Box of Tools at Sears

When I go to Sears and browse the Craftsman (or DeWalt) tools, I usually see some interesting little specialty tools. I might buy a funky swivel socket or a single ratchet, but I rarely browse the aisle with the large all-in-one kits. The reason I don’t browse the kit aisle is because my father-in-law bought be a basic Craftsman starter kit almost 20 years ago and my collection of tools has grown over time.

I don’t still have all of the tools in that original kit, but I do still have many of them. Further, my need for hand tools have gotten more specialized over time. Also, I am making a bit more money than I was when I married my wife, so I may spend extra for a special-purpose hammer rather than always relying on the one that came in the original kit.

Without that original kit, though, I would never have been able to even get started. No, it didn’t have every tool I would ever need, but it had almost everything I needed right then.

Team System is much the same. A team can absolutely hit the ground running with the rich toolset VSTS provides. Maybe you’ll augment the toolbox over time. Maybe you’ll even change tools (can anyone say [TestClass]?) but the kit that comes in the box really can provide most of what a small team needs to get going, and do it in a single solution.

That’s huge.

As soon as I start looking around to sub-optimize my hammer or my source control, I am going to start slowing the team down. GIT? SVN? PerForce? There are a ton of options for source control, each with their strengths and weaknesses. It’s freaking source control. Get on with it. I mean, how sexy can a hammer be?

It May Not Cost What You Think

You can buy a big toolkit at Sears for far less than it costs to buy all the tools individually. Further, buying the toolkit for the person without tools is a good move because they will have all the basics covered in a single purchase.

Craftsman Toolkits are a favorite gift of mine for graduates and newlyweds for this very reason.

Microsoft has the same insight that Sears had. If a person gets accustomed to Craftsman by selling the kit cheaply, they’ll be a customer for life. This is the exact idea behind the BizSpark program. If you aren’t familiar with it, BizSpark is a Microsoft program that allows free (that’s right, free!) access to all developer tools, operating systems, and other software for startups.

Is your company less than 2 years old? Do you make software? If yes, you qualify, I kid you not.

Integration Matters

Even if you are paying full price (which you shouldn’t ) I believe the value of VSTS is still there. The productivity loss involved in setting up a system of disparate and non-integrated developer tools is tremendous. I have been there and done that.

I know SVN is good. I know Team City is good. I also know that setting up a basic Continuous Integration build in Team System is stupid simple. And the real money shot comes with Work Item management. How many teams out there are using work item management systems or defect tracking systems they hate?

Well, we all are.

So, we may as well have one that works right in the IDE and allows me to tie check ins to work I am performing. The context switching that occurs in non-integrated systems of reporting, SCC, build, and work item management is HUGE. Huge! No really.

Get On With It

The people involved in the recent online Team System kerfuffle are folks I would consider in the top 1% of developer talent. Quite frankly, it makes a lot of sense to me that people at that level will have replaced their hammer from the kit with one that has an ergonomic grip.

That said, there are a lot of startups and small teams in entropy out there. For those folks, I firmly believe that standardizing on an integrated toolset for the development team is a bigger savings than “free like a puppy” solutions that can work well, but with more churn.

Now quit fussing about source control and learn how to use a decent ORM, people.

This is because the default is for svn to update folders down to the working copy depth: only check for updates in folders that you’ve already got.  New folders beyond that are beyond the depth and won’t be updated.

To get all of those folders, in Tortoise SVN select “SVN Update to Revision”, and change the update depth to “Fully Recursive.”  Or from the command line, “svn update –depth infinity”

[Note: I may have gotten some or all of this completely wrong, this is just my notes as I’m trying to understand how svn is doing what it’s doing.]

At Blackfin, we use SourceGear Vault and CruiseControl.net. (We’re moving to Subversion and TeamCity, but that’s a different post.)  One of our projects on one of our CC.NET servers was failing with this exception:

“The working folder state information for C:\CruiseControl.NET\Build\MyProject\working is incompatible with this version of Vault.  Please choose a different working folder path.  The specific compatibility exception was: Could not detect the file type in the supplied stream.”

Vault likes to litter your system with lots of little state files, and on rare occasion these files get corrupted.  To fix, you just delete the local cache directories, re-get repositories, and you’re on your way again.  Piece of cake. 

I deleted all the cache files on this server, from C:\Documents and Settings\{username}\Local Settings\Application Data\SourceGear.  To be thorough, I delete all the cache files I can find for all users.  BUT, the exceptions continue.

Thinking to myself, “well obviously I’ve not deleted the right directory” I run a search for all directories named “Vault_1”, which turns up…nothing.

What follows next is a bunch of flailing about, checking for cc.net bugs, and to sum up: grasping at straws.  What *should* have happened is that I re-read the exception and think carefully about what causes it: a corrupted state file that I haven’t deleted yet.

I run CruiseControl.Net as a service, under the local NetworkService account.  Therefore, I [failed to] reason, the cache files must be in C:\Documents and Settings\NetworkService\Local Settings\Application Data\SourceGear.  But I couldn’t find this directory on the system.  Except that the NetworkService directory is marked as a “protected Operating System file”.  Remember that Folder option “Hide protected operating system files (recommended)” that you always switch off and ignore the dialog box that pops up?  It was still checked…

Uncheck that dumb setting, go into the directory, delete the cache, and now the build works again. 

Lesson: sometimes exceptions tell you exactly what’s wrong.  Don’t be so quick to search for exotic solutions when the obvious one is staring you in the face.

My default recommendation is to do a clean, fresh, manual import rather than to migrate source code with existing structure. I have several reasons for this including:

• Code migration is more complicated and it will take longer (cost more).
• Tools have flaws. Everything may not turn out the way you think it will when you have been branching and labeling in that old system for 6 years.
• The majority of code file comparisons occur at the tail end of source control. Very rarely is a comparison made on a code file in SCC older than 60 days.
• The reason you want to retain history is to blame that guy.
• Your branching model was probably over complicated anyway.
• History for auditing purposes can be found in the old system, kept online and read-only for a year or two if necessary.

But the number one reason I don’t want to bring the source code over in the same model is because this is a golden opportunity to improve.

It amazes me that the structure of a SCC system reflects the nature of the organization that created it. I have learned, however, that it does. Are management decisions hectic? Are releases going out buggy? Look for lots of deep branching structures. Are developers working in separate branches on the same release? Look for lots of cherry pick merges.

It is a fundamentally healthy exercise to pull a large pile of source code out of the old system and bring it into the new one one project at a time, ensuring that each one is self contained. In other words, break the dependencies between projects and all of those weird references to resources outside the boundary of the solution.

It comes down to this, why are you making this tooling change in the first place? Odds are that the tool change is being done because the team wants things to get better. Whether you are moving to Team System, SVN, or something else, you are moving to a new system to make an improvement. Given the desire to improve, take advantage of the opportunity to actually make things better rather than to persist old dysfunctions into a shiny new tool.

As a manager of development teams myself, I found great value in migrating source control every 2 years or so, just to cause such a spring cleaning event.

And the number one thing you can do to make this a true Kaizen event? Ensure that each and every project (that is, every *.*proj file) gets build built via a CI build before adding another project to the system.