What Tools Do I Use? (Part 01 - Repository Tools)

Since I started doing .NET development back in the days of yore (when the first Beta came out), I've accumulated a variety of tools and products that I use over and over. I thought it might be useful to others to list them, with links where appropriate. Basically, I go for Open Source (i.e. free) tools. There are certainly a lot of them available. However, not all of them are good. If I use them over and over, and recommend them to others, then they have met my nebulous definition of good.
When using Open Source tools, my first criteria is: does it do what I want or need? Then I look at whether there is a "stable" release. I've learned not to use "alpha" or "beta" releases. Next I look at how recently it has been updated.  If no one has touched it for a year or more, I generally won't use it. Third, I try to see how many users there currently are. A product with 12 users, regardless of it's stability rating or frequency of update, just doesn't have much of a future. Finally, after I've installed it, do I keep using it? Does it play well with other related tools?  Does it actually make my development life easier?  If I have to open a Command window to use the tool, I throw it out.  If I have to have multiple windows open to move information around, I throw it out.  With that set of criteria in mind, here are my favorites that I deem "good":

• Project Locker (https://projectlocker.com/): Everyone needs a repository. I could do this at home, but then I have a bunch of stuff to back up, have to install server updates, etc. Project Locker offers free repository services for small projects. Since most of my projects done at home are smaller, they fit in this category. They also have paid services for larger repository requirements. They offer SubVersion and Git repositories, and a wealth of project management software as well. Having a repository for even small projects has saved my a** more than once.  Never start a project without one...
• TortoiseSVN (http://tortoisesvn.net/): Once you have a repository, you need a client tool to access the repository. This one has a GUI interface, and adds menu items to the Explorer context menu that allow you to interface to your repository right from Explorer. In addition it has a set of folder icons to use in Explorer, that show you graphically the state of your files and folders vis-a-vis the repository state. This tool is absolutely wonderful! 
• AnkhSVN (http://ankhsvn.open.collab.net/): It was a bit of a toss-up deciding in which category to put this: in the "Plug-in" section, or "Repository Tools" section? I finally decided to put it here, because its main purpose is to interface with a SubVersion repository. This is a plug-in to Visual Studio that (as does TortoiseSVN in Explorer), shows you the status of your files in your solution/projects. If you are using Visual Source Safe (AAAARRRRRGGGGHHHH!), or TFS on other projects (like at work), this has a similar interface - except for a SubVersion repository. 

By the way, unlike TFS or VSS,  using TortoiseSVN, SubVersion, and AnhkSVN it's very easy to work disconnected.  Plus the updates and commits seem to be much faster. Finally, all of these play very well together.

Signs Of A Project In Trouble

Recently I had a contract at one of our local banks (to remain un-named in this post). After about the first week, I knew we were all in trouble.

• I was a new resource being brought on less than two months away from  the scheduled delivery date of the first release.
• The primary developers on the project were all working 10, 12, 14 hours per day 6-7 days a week - for the last several months, and the whole short time I was on the project.
• They claimed to be doing "Agile", but our standup meetings were lasting 45 - 60 minutes each day.
• Their "burn down" chart was an Excel spreadsheet (a very clever one) with a worksheet for each sprint that only the Scrum master could update, and was updated during the standup by everyone giving their hours worked rather than the number of hours remaining.
• Reviewing past sprints I realized that their initial estimates of effort compared to the actual effort recorded was off by 30% - 150% over the various sprints. Yet they kept making the same sorts of estimates at the beginning of each sprint.
• Their concept of velocity was based on how many effort hours they achieved, rather than how much work was completed.

There were other factors too numerous to mention at this point. This bank is also known for simply defunding projects. In the last 30 years, I've worked there a total of 3 times. This was the first project I was on that was de-funded, but each time there was some project that was suddenly de-funded.

So, after two months of being on the project, one day it was announced that they had failed to receive further funding from the internal customer to complete the deliverable that was due a month earlier...

Fortunately, I had anticipated this, and already had another contract lined up. A happier place to work, at a higher rate of pay, with more control over the product deliverable.

O frabjous day! Callooh! Callay!