I scared myself this morning, I thought I had managed to get the testing policy to ignore inconclusive test results and allow check in for change sets that had no business doing so.

We use sub lists, that is to say we have a few master test lists that are parents to several sub lists of tests. It seems to make dealing with many tests a little easier. When you initially set up the testing check in policy for a team project you select which test lists you want it to ensure pass before the user can check in.

We started with a single list, and added sub lists at whim and will, wherever the need arose basically. However what we didn't realise was that, if you don't go and update the testing policy to watch your shiny sub list, any failures or inconclusive results will bypass the policy check. 

It would be nice, although its not imperative, if the testing policy could automate this process so we plebs don't have to remember. If you happen to agree, then submit your vote to Microsoft connect here.

Hooly dooly batman, as it turns out, if all goes well between now and April/May 2008 we will be the proud and bewildered parents of identical monochorionic, diamniotic twins.

Interestingly, according to the repository of all knowledge, identical twins do not occur as a hereditary predisposition (as with fraternal twins), but rather as a random event distributed evenly across all populations. I don't think I will ever look at GUIDs the same way ever again!

I'm such a stunned mullet I can barely type, but needless to say my wife and I are absolutely ecstatic at the thought of having two bundles of joy. I didn't think I could get any happier. Wish us luck, we're gonna need it :)

I forget every now and again that VSTS Test runner does not run your shiny test suite in place, it makes a new folder for each test run and....well you know the story.

 So this post is really just here to remind me that if I want to read in a file or have some other file system dependancy in a test then I really must apply the DeploymentItemAttribute to my test as well as setting it to copy to the output directory in some fashion. Oh, and I can get fancy by using the OutputDirectory property of said attribute if need be.

*sigh* If I say it often enough I will remember...

...I will use DeploymentItem and not scratch my head as every test fails...

...I will use DeploymentItem and not scratch my head as every test fails...

...I will use DeploymentItem and not scratch my head as every test fails...

It's been a while since posts, and I have a few brewing so stay tuned, but I found out today that my wife is pregnant and I'm going to be a Dad. Wow!

I'm so excited!

Jeremy Miller's post on software teams berates the use of strict enforcement mechanisms of development processes, in favor of a more nurturing environment of self awareness and coaching. He writes:

Quality gates are a very common tool in software development processes to enforce quality by making the people on the project demonstrate some sort of compliance to a standard or process before the project is allowed to proceed.  I'm not sure that I'd say that quality gates are necessarily a bad thing at all, but by themselves, quality gates are absolutely worthless in promoting software quality.

I wholeheartedly agree. Personally, I like to see the odd quality gate, simply so that people are periodically reminded that quality is an issue. However the overuse of gates will simply lead to process apathy.  One of the reasons why I feel such checks are usually pointless, is because they check for the symptoms of good behaviour, rather than rewarding actual good behaviour itself. Besides, we all know that where there are systems of forced quality assurance, there are people who will deliberately pay lip service to prove to themselves that they can beat the system.

Teamwork is about trust and communication, and no amount of Office Nazi-like behaviour is going to produce more of either qualities. Participating in a team must be about nurturing these qualities. By imposing hoops to jump through, you prove you don't trust your fellow team members. By dictating progress rather than collaborating on it, you are denying your team the ability to communicate effectively with you. 

If you don't trust your team members, or you aren't interested in their opinions, why are you working with them?

I came across a cool looking TV show on G4TV, and it's fashioned in the classic style of 8 bit graphics. Entitled Code Monkeys, I think anybody who owned one of these books or similar as a kid, will appreciate this for at least 5 minutes.

It's not for the faint hearted or easily offended though. Personally, I'm hooked and I can't get enough. Have a look at the previews.

I'm not sure what to make of this. Deftflux has created a library to aid brave C# developers in their dark quests to use duck typing.

Given that C# 3.0 is around the corner with anonymous types I feel the duck typing library is a bold move towards Rubyesque abilities. While anonymous typing only gets you some of the niceties of duck typing, I think the greatest advantage of anonymous types is compiler checking goodness.

There is no doubt duck typing can save a lot of time coding. I admire languages like Ruby for their declarative, artistic form of expression. The .NET framework makes use of it too; duck typing has very real use cases.

The TDD crowd has a distinct advantage over the rest, in that one could happily duck type all day long, trusting in the safety of ones unit tests to provide alerts to type mismatches.

 Sure, if you write a thorough test suite you can theoretically avoid most of the dangers of duck typing. Though all it takes is one hole in the tests and the time saved coding is spent debugging. I would rather my compiler tell me about a type mismatch, than the beta testers complaining of unhandled InvalidCastExceptions. In the spirit of using the right tool for the job, surely the compiler is the right tool to inform us of type mismatch problems? It does a fantastic job of it. Cedric Otaku puts it in a way that's hard to ignore:

In a way that's typical for dynamically typed languages, the error will therefore only appear at runtime and only if such code gets run.

If you are duck typing in copious amounts and not writing tests, then you are walking on shaky ground.

I guess I like to be explicit in general; say what you mean and mean what you say. Life is simpler that way. I like suspense & innuendo in movies, not code. I can't wait for anonymous typing in C#, but perhaps even more so, I look forward to the day work lets me use languages like Spec# to enable me to be even more explicit to the compiler as to my intentions.

I often see superfluous use of Me.This and this.That lying around in code and it always bugged me, but tonight I found a reason it might be more than just my anal nature. Typing 'Me.' or 'this.' is not a clever way to fire up Visual Studio's Intellisense drop down. The Ctrl+<Space> keystroke is a much tidier, and quicker way of getting there.

Sure, there are circumstances where you need to use these keywords, for instance when you need to differentiate between your class and your base class. Me and MyBase, or this and base are valid ways to get around in that case.

The benefit of refraining from using these keywords until its necessary is that you could reduce the cognitive load on someone who has to understand your code. Every time you avoid the use of the Me keyword you will decrease your maintenance complexity score by 2 points every time you do so. In functions that address members heavily, this could represent a significant increase in the readability of your code.

So what is this metric, Maintenance Complexity? Its an idea coined by Mark Miller from Developer Express. Its been a feature in CodeRush and Refactor! Pro for some time now. The 2008 release of Visual Studio, codename Orcas will also provide code metrics visualisation. Simply, it recognizes the fact that the more code you write to achieve a goal, the harder that code is to maintain. That is to say, if you can achieve the same goal in less code, you have written it in a more maintainable fashion. It has been said before, the best developers code smaller.

Each type of construct attracts a score, much like letters do in the board game, Scrabble. At the end of a function you are scored by adding the values of each construct up. For a complete description of the metric, please visit Mark Millers blog entry on his creation.

There are some valid criticisms to this metric, and simply refactoring in aid of reducing MC scores is only cheating yourself. As such I suggest the reader use code metrics in general as an indicator rather than a developers divining rod.