How to Know You're on the Right Track

I noticed recently that whenever I'm trying to find a solution to a problem, I feel as if I can tell I'm going in the right direction by the amount of obstacles I run into while solving.  I'm not suggesting I've found my internal compass for coming to good solutions, nor am I suggestions that my solutions are the best.  Far from it.

Whenever there's a technical issue with a problem I'm tackling, my first and only thought is, "I can't be the only one to have ever come across this problem before."  And then I ask the Google who has conquered this hill already, and it tells me that some user on StackOverflow.com happens to have done this exact thing. Hopefully.  This single guiding thought is what gets me through most days.

And sometimes, it's not so easy to find someone facing your particular issue.  I've actually met teams whose technical hubris is so great that they believe their personal genius is indicated by the fact that no one has solved their problem.  That they are a unique flower solving problems in the most awesome way.  So often, however, it's because they've gone so far off the beaten path that they can find no one else in their situation to help them.

Let me talk through a hypothetical:

I have a web site I've built.  I need to get it deployed to a place where someone can see it.  I could manually build the solution, and copy the files to a server.  That's easy.  But then I start deploying more often.  And because I want to push changes so frequently, I end up spending a larger percentage of my time deploying instead of delivering business value.

So I have a couple options.  I can either grab a COTS (Commercial, Off-The-Shelf) solution that can build and deploy my software, or I could write a batch file that does a dos xcopy and be done with it.  There's a learning curve associated with the former solution, and almost none for the latter, so I go for the xcopy script.

Now I'm a couple years down the road.  I never wanted to take on the learning curve of TFS or Team City or Octopus or any of the other build/deploy solutions there were out there.  It doesn't take long, except now I might have four environments across many different products.  What was one xcopy batch file has grown to many nicely refactored batch files, and the parameters passed in correctly build and deploy my solutions across my enterprise.

All I've done is spent the cost of learning and purchase of the COTS system over a much longer period of time.  And who knows, maybe because it does what I want and only what I want, I've done it for cheaper. And it works.  What's wrong with that?

Well, nothing really.  Except you've committed to this solution, and every time something new comes up, it's a new problem that has to be solved.  Need to deal with restarting application pools, services, change configs, it's a new problem.  You have to spend time figuring out how it works in your framework.  When anyone new joins the team, there's a non-trivial learning curve to it.

Now let's rewind time and take the other path:

Say at that critical juncture, I went with a COTS solution.  When I need to do something new, because there's a larger body of people using the same solution, the likelihood that any particular problem you face has been solved goes way up.  With communities like StackOverflow out there, it's easy to find the information you need.  Not how to cobble a solution together from duct tape and baling wire, but to leverage the tool in the ways it was intended.

So with my home-grown solution, every problem I have compounds, and it gets harder to find a solution to my singular little problem.  Every patch to my system becomes hand-crafted.  And involving anyone else to aid gets harder.  With the COTS solution, every time I need an answer, there's more likely to be someone that's already solved my problem.

This is not to argue for build/deploy systems, or make a case for buy vs. build.  This discussion is only to illustrate the point: one way of knowing you're on the right track is when answers to your questions get easier and easier, not harder and harder.  This whole concept seems to be related to the Pit of Success, or even Stacking Functions, but that's a discussion for another day.

Also, I want to point out that these arguments all go out the window if you're intentionally trying to innovate. For lots of solutions, including build/deploy, that's probably not you.  If you're writing a bunch of custom devops tools to work around your solutions, for instance, that can be a smell that you're not going in the right direction.  If you are a small company who wants to build the best new build/deploy system out there, however, then being off the beaten path may be a sign that you're going in the right direction.

I've often heard it said, "buy commodity, build competitive advantage."  This advice is intertwined, I think. If you're working on commodity problems, pick up commodity solutions so the answers are out there.  Save your energy to innovate on the tough problems your business faces. They truly need you, and they trust you to make these decisions.

DVCS and the Pinocchio Test

I know in this day and age there are still folks out there not using source control systems.  I can't help that. This post isn't for you.  Sorry.

I also know that there are some folks out there still using VSS.  Stop.  Do you not listen to your architects? Do you like having to deal with exclusive check-in/check-out locks?  What's the matter with you?

Even TFS, with its central hub, seems a bit quaint to anyone not stuck in a Corporate IT gig where you're forced to go with an on prem solution.  Sheez, at least move that stuff to TFS online.  But whatever.  At least you can merge and have simultaneous editing.

Yeah, I feel all the cool kids tell me they're using DVCS systems.  Cori Drew got me excited about git (though I don't use the powershell command line personally), and I've since used it for both part time work and my personal projects.  In my new organization, we're using Mercurial, so I'm getting to see this side of things now. My only personal regret is that I missed the Subversion era.

And for the most part, these DVCS systems are awesome.  There are some hassles, and you can get yourself in a real twist if you're not careful with branches, but overall, I quite like the experience.
One of the biggest issues I have with using DVCS systems (doesn't matter, Git and Hg have the exact same issues) with .NET is that the .csproj files are so fragile.  Two people want to add files and/or references to the project at the same time, and Visual Studio seems less than consistent about where it puts stuff, often leading to merge conflicts.  And get that merge wrong, and whoo, you are in for some rollbacks.

So here's my recipe on how to handle this.

1. if you're going to add a file or reference, do that first.  Add the empty file and the reference and check that in immediately.  You're adding an empty file or reference, so generally you're not going to break the build.  The point is to keep that .csproj file change open and out there for the minimum amount of time.
2. I like to make sure that my tests are picked up and running, so I'll often write a Pinocchio test.  What's that?  Goes like this:

namespace MyNamespace
{
    [TestFixture]
    class MyTests
    {
        [Test]
        public void PinocchioTest()
        {
            //I wish I were a real test
        }
    }
}

This cracks me up every time I see it, too.  I read it in the voice of Pinocchio from Shrek.

Fixing My Custom TFS 2010 Activities to Run on TFS 2012

Wow, what a technologist.  A post or two a month about everything except technology.  Well today, I'm going to document one of my most recent struggles in the hope that someone will benefit.

Started off getting this error.

TF215097: An error occurred while initializing a build for build definition \<My Project Build Name> The values provided for the root activity's arguments did not satisfy the root activity's requirements:'DynamicActivity': Expected an input parameter value of type 'Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings' for parameter named 'BuildSettings'.'DynamicActivity': Expected an input parameter value of type 'Microsoft.TeamFoundation.Build.Workflow.Activities.TestSpecList' for parameter named 'TestSpecs'.Parameter name: rootArgumentValues

Bizarre.  So what it comes down to is that 2012 does not work with artifacts either built against or referencing a component from 2010.  A 2012 build controller won't run custom build activities (which I had) that were compiled against the TFS 2010 binaries.  Further, the custom XAML files were polluted by the workflow designer, said to be a bug in the designer, but that smells fishy to me.

Here's the steps I took.

1. I rebuilt my custom activities with all the references pointing at the new 2012 TFS .dlls.  
2. I overwrote the old custom activity .dlls in the $\BuildProcessTemplates\CustomActivities directory and checked them in.
3. After that, my builds still didn't work, failing with essentially the same error, so I used the XAMLCleaner code I found here to scrub my custom build workflow templates (.XAML files).
4. Running anything and causing one of these version issues requires the build controller to be reset.  Use the TFS admin console to do so.
5. My *.CI builds all use the DefaultTemplate.xaml.  The upgrade gave me a DefaultTemplate.11.1.xaml.  I deleted the DefaultTemplate.xaml locally, renamed the DefaultTemplate.11.1.xaml to DefaultTemplate.xaml, and checked it in.  .CI builds ran fine.
6. Once I had made all these changes, I checked everything in and ran my custom web and default release builds, and they worked.

Hope this can help someone.  I love TFS ALM, but sometimes the stuff is daunting.  The two links above really helped me out.