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.

In my last post, I outlined why I felt that tab order is an easy way to measure your GUI's complexity, and in this post I intend to show you how. Bad tab order is on my top 5 pet peeve list, so it's one of the first things I look for in an application. As you can see, even the simplest of UI's can be over engineered, and layout metrics that are purely concerned with user interaction wont pick it up. Turning on the View > Tab Order will show that the devil truly lies in the detail.

Nested panels adjacent to more nested panels will make for some mind exploding tab ordering, as shown in the example above. This is definitely panel overkill, or panelcake as I have affectionately dubbed it, and the main culprits include the ToolStripContainer, the SplitContainer, the TableLayoutPanels, and finally the GroupBoxes. The depth is so great, the tab order obscures the design!

YAGNI applies to GUI's too, so lets rescue this poor innocent interface...

In Visual Studio 2005, I press the Ctrl + W, U key chord to bring up the document outline viewer. This tool is absolute gold for rearranging hairy container hierarchies.

Step 2, set the window style to Fixed Window. Unless there is a compelling reason to be able to resize then there is no point in offering it. If it is needed, then careful use of Anchor and Dock properties will suffice for the most part. TableLayoutPanels should be used sparingly. YAGNI all the way.

Next, I lose the ToolStripContainer. Its function is to provide a drop target for ToolStrips and MenuStrips on the outer extremities of your Form. Does the user need to move the menu or tool strips from the top position? Nice idea, but probably not.

I continue to carve into the UI, removing all of the table layout panels and the split container until I am left with the fewest amount of controls to represent the data I need the user to edit. Careful choices for anchoring replicate much of the TableLayoutPanels functionality. Some grouping is beneficial to the user, and doesn't hurt when you need to alter the visibility state of groups of controls. What I am left with is a form that achieves the same end as the original, trimmed of unneeded function.

The acid test is that I can set the tab order in roughly 10 clicks of the mouse button. Not to mention the fact that you can see what you are doing.

Graphical user interface design is a subject dear to my heart, as it should be to most GUI developers. However, creating a useful, efficient and ergonomic user interface is easier said than done. All too often I see (and in the past have written) applications that just clearly get it wrong. There is nothing more frustrating to me, as a programmer, than using a poorly planned UI. Some UI's make you feel as though it would be quicker to write the program yourself.

 So what is the proverbial canary in the mineshaft for a user interface? I've compiled a list of things I feel are good signs that your GUI needs a birthday, however since the list got quite long, I felt compelled to break them up into a blog mini series, so here goes...

When tab order is a nightmare

I know that tab order is that UI chore we all leave until the last moment or when the tester has run out of things to pick on. Incidentally, its the first thing I look at when deciding whether or not I like an interface.

If you are thinking about either buying or creating your own tool to help you sort out your tab order, then stop for a second have a think why. Sorting your tab order should be as simple as clicking on your controls in the order you would like your users to visit them.

A lot of research has been dedicated to UI complexity and metrics, and like your cholesterol count, you can ignore them at you own peril. I can't say I know much about the various computer science techniques to measuring UI complexity, but I do have my methods. Tab order complexity is my cheap and nasty, poor mans metric for GUI layout appropriateness. In my next post, I'll show you why.

I've been struggling with the concept of DI & IoC for a few weeks now. Its not because I don't understand the concept, or the benefits, I struggle with the implementation details. I'm one of those horrible visual learners who needs to see code  before the penny even gets close to dropping.

I found my holy grail of information today, and it was lurking right underneath my nose. I've only recently subscribed to Jeremy Miller's blog and the latter chapters in his series on building your own Composite Application Block seemed a little 'pie in the sky' for me. Ooo boy, was I wrong.

I started at part one this afternoon, and have been reading page after page of excellent content for the DI newbie.

So if you're in the same boat as me, struggling with the question; "How do I create a rich WinForm app, that is comprehensively unit tested, without sacrificing furry animals to the dark gods of the Enterprise Library?" then treat yourself to Jeremy Miller's series on building your own lightweight CAB.