Team System Widgets

I am still trying to find more value in the Team System/TFS combo.  There are some really great benefits that we are seeing in terms of using TFS for our source control, but a lot of the things I had hoped to do with TFS are simply not good enough to actually use.  Unit testing, continuous integration, bug tracking, code policy etc.

Here are a list of addin widgets for team system:

I’m hoping that some of these can provide some added value to the entire system.


3 things I learned in (and out of) college

Dare Obasanjo has a post on the “Three Things I Learned About Software in College,” to which Scott Hanselman followed up with Three Things I Learned About Software WHILE NOT in College.

So here are my 3 from each category:

Learned in college:

1) A lot of people getting a CS degree will never be able to write a real program (as I was getting my degree in structural engineering (CE)).

2) New features and scope creep can cause projects to be never ending, and end up not being released at all.

3) How to really work hard, really study hard, and really focus on a task with a fast approaching deadline.

Learned OUT of college:

1) Just because someone has “Sr.” in their title doesn’t MEAN they know anything, but they might.  If their logic sounds flawed, don’t assume it is because they are “Sr” and you are “Entry”: you are probably right.

2) “Expert” can mean different things to different people.  You can be in the top 2% of one company, but a middle of the pack guy in another.  Avoid calling yourself an “expert” (or acting like one) unless you know who you are talking to, and you actually are the expert.

3) There is no “Best” way to do most things.  I had thought that if I looked hard enough and studied enough examples, I would know the “best” way to do things when I arrived at them.  But one groups “best practice” is something another group will not touch.  See the current OR/M arguments for a perfect example, or if you prefer just look at divide over using Datasets. 

That being said, there are definitely some agreed upon “Worst Practices”, so avoid these at all costs.


I saw a link from Scott Hanselman’s site to, which is looks like a community site for programmers.

I have been looking for a forum for software consultants like myself, so I will have to check out the forums:

There is the “Caffeine Lounge”, which sounds like the perfect place for me.  When the guys at starbucks start your order before you say anything, you have probably been in there too often.

17xx-Controller in lock up State

I had one of my clients call me today with this message showing up on their production server after the power went out (big storm in the area):

17xx-Controller in lock up State

The server is old, and so I started to think worst case scenarios:  the controller probably died, the data is probably lost, backups probably don’t have everything, we are going to need a temp server, we are going to need a new production server etc.

Thankfully, this did not come to fruition, so if you get this error message on your Proliant, there may be some hope.

Go into the setup menu for the raid controller and you should be able to clear out the lock state simply by saving the settings.

Of course if your controller really did die, then this won’t help you.

Plasma Unit Testing

I came across this CodePlex project called Plasma which is supposed to aid in testing web apps with standard unit test frameworks.

I couldn’t find much info on their codeplex site, but I will be keeping track of it to see if I can find some info.

Managing the number of assemblies

Scott Hanselman has an article on trying to pick the right number of assemblies when creating an application.

Much of my work is on a large intranet application, which brings lots of considerations into the fold.  We have started segmenting different web applications into their own projects, meaning they are seperate applications in IIS.

Of course this means that common functionality now needs to be broken out into assemblies.

Also, we had the practice of creating 1 data access assembly for each database we touched.  This was pretty simple at first as we only had a handful of databases, but now have 16 of these assemblies, am I am starting to think we should just merge them all into 1.

I downloaded a trial of NDepend which produced a pretty neat diagram connecting assemblies together.  I am going to try to see if I can refactor out a few (maybe only 2 are options at this point).