Caffeinated Coder

Monitoring and enforcing code quality seems to be somewhat of a holy grail in the software industry in that nearly every development shop pursues this goal but few ever even come close to actually achieving it. Here are a few of the common failed approaches I’ve seen:

• Developer’s Handbook - Despite being a darling of auditors, I find this approach to be a largely worthless exercise for anyone except perhaps the author of the document. Like all waterfall-based functional specifications, these documents quickly become outdated and are seldom read and often misinterpreted by developers. Even in ideal circumstances where developers are highly motivated to follow guidelines that are well understood, this honor system approach falls hopelessly short simply because of basic human fallibility. Logical mistakes in code are caught because users, testers, or unit tests complain about something not working, but how are code quality mistakes caught?
• Code Reviews - After becoming disillusioned with the honor-based rules approach, many shops attempt to supplement their developer handbooks with a manual code review process. Although a second set of eyes increases the odds of catching errors, this approach is extremely expensive to implement and subject to all sorts of emotional pitfalls that can easily turn the review into either a meaningless rubber-stamping exercise or an ugly battle of egos. Even with the most mature and disciplined developers, this approach ultimately fails to provide the level of code quality that shops are seeking due to a lack of knowledge or simple oversights by the reviewers.
• Architects - In order to maximize the effectiveness of reviewers, shops might take the step of designating a specialist, such as an architect, to be in charge of overall code quality. Unfortunately, whatever advantages that this position brings to the review process in terms of technical knowledge and increased authority are often nullified by the specialist being too far removed from the code to appropriately identify issues or too far removed from the team to effectively enforce changes. Even when the specialist is viewed with respect rather than ridiculed as an out-of-touch Architecture Astronaut, suggestions tend to be seen as too subjective to be actionable when compared to hard deadlines.

Now for some more promising options that I’ve seen…

• FxCop - This tool analyzes source code and produces a list of violations where code doesn’t comply with a set of preconfigured rules, such as naming standards. By relying on software rather than people to enforce code quality rules, you dramatically decrease the chance for error, the perceived subjectiveness of the process, and the overall cost. Unfortunately, static analysis tools such as FxCop are only capable of monitoring a certain class of the more superficial rules and don’t catch logical errors or help identify more complex code quality issues such as cyclomatic complexity, low cohesion, excessive dependencies, or overly complex interfaces.
• NDepend - This static analysis tool picks up where FxCop leaves off by providing visualizations and SQL-like code querying capabilities to identify the areas of the code that suffer from low cohesiveness, excessive complexity, and inappropriate dependencies. More importantly, it provides a big picture view of a code base that allows developers to identify and prioritize issues with the entire code base rather than just issues pertinent to the particular piece of functionality being implemented. This allows someone like an architect to effectively analyze a code-base without having to be intimately familiar with all of the details and provide objective evidence to backup any recommendations for making changes to the code.

Although I firmly believe that static analysis tools provide the most cost effective gains in code quality and should form the first line of defense in any shop’s quest for code quality, I do think that manual reviews should still figure into the equation. Tools will never be able to verify whether code is soluble or that code logically satisfies the user’s intent or that IT shared assets are effectively being utilized. I even think that a Developer’s Handbook can provide value as long as it remains a living document that offers light-weight guidance rather than trying to exhaustively cover low level details that are ultimately technology specific and subject to change.

For anyone interested in learning more about NDepend, I recommend starting with this old Hanselminutes podcast followed by this quick 3 minute online demo of the code querying language in NDepend. Expect more posts from me on this most excellent tool in the near future.

Here are a few scenes from the first day at my new job:

• My welcome kit consists of a coffee mug, a pen, and a DVD of the Big Lebowski. My new boss is a huge fan of this movie and several technical artifacts and regular meetings are named after characters and scenes.
• As we are leaving for a group lunch, I quickly run back to my desk because I remember some friendly warnings about what happens to people who forget to lock their computers. Apparently any of a number of fetish sites is likely to be prominently displayed when you return.
• I suffer through an enthusiastic rendition of “If You Believe” by Cher from a few of my new co-workers. This appears to be a ritualized part of a certain surreptitious installation process. Enough said…
• I hear a torrent of indecipherable curses interspersed with the words ‘dirty Gypsy’ that are directed at the developer who sits next to me. His practical joke is apparently under-appreciated by the developer on the receiving end. The victim later explains to me with a smirk that the prankster is Romanian and takes particular offense to being called a Gypsy.
• The lunch crowd votes that the largest group member (at least 6′5” by my reckoning) must squeeze himself into a car that would be considered under-sized in Europe. Everyone lingers to gawk at the spectacle and at least one person attempts to take a picture with his camera phone.

I think I’m going to like it here…

I used Resharper’s unit-test runner for the first time while spelunking WatiN last week and quickly became a fan. If unit-test runners were high school boys, here are a few reasons why the Resharper test runner would be dating the entire cheer leading squad while the NUnit test runner would have to bribe a distant, homely cousin in order to get a prom date.

• Integrated IDE experience: I think NUnit is good for deployment scenarios when you just want to load the test dll and verify the environment, but using a unit-test runner that is not integrated into the IDE is too frustrating for me when it comes to normal development. I used NUnit exclusively for several years, but I’ve been too spoiled by TestDriven.NET, SharpDevelop, and even MSTest to want to waste any more cycles switching between applications.
• Navigation between Tests and Code: Resharper lets you run tests by right-clicking anywhere in the test code (similar to TestDriven.NET) or by clicking on the ’gutter icons’ to the left of the code window. You can navigate in the other direction by simply double-clicking on the test icon, a feature I often use when investigating why tests fail.
• Ad-Hoc Test Groupings - The only way to organize groups of tests that can be run together in NUnit is through namespaces. This works fine for groupings that you could plan out ahead of time such as fast-running vs. slow-running tests or tests that share common dependencies. However, if you do have to run tests from different namespaces in the NUnit GUI, the only way to do it is to highlight and run one test at a time (you can’t even use the ctl-click option to highlight multiple tests). MSTest made a step in the right direction with their test list by allowing you to simply drag tests from different namespaces into a list, however Microsoft made the mistake of only including this feature in the Team Suite edition (which costs $10,000 plus an primary appendage) and also only allowing a test to belong to one list at a time. Resharper solves this issue by allowing you to add any test to a Test Session and also by implementing the Ctl-Clicking functionality to highlight multiple tests. There are also filter buttons on the toolbar that allow you to do things like only rerun the tests that failed.
• Test Validity Status Monitoring: If you have changed and rebuilt your code without rerunning your tests, little question marks appear over the red/yellow/green icons. Depending on the size of the project and your use of shortcut keys, rebuilding can become an automatic reflex like saving a document so it’s nice to get a smart reminder about whether or not your last test results are still valid.

Let me conclude with a disclaimer that I am primarily talking about the best way to run test written with the NUnit framework. When choosing between frameworks, I am now an advocate of MBUnit for reasons I’ll outline in a future post. 

Participating in the open source community and becoming an avid code reader were two themes in my six month roadmap to becoming a better developer. I made progress in both of these areas in the last few days by downloading and exploring the source code for WatiN, an open source library that I have used recently for creating automated web tests. I still have quite a bit more exploring to do before I’ll fully grok how WatiN works, but I thought I would share a few of the code reading techniques that I’ve been finding helpful.

My preferred starting place on any new project that has good unit test coverage is to pick some unit tests for common scenarios and then run them through the debugger. I chose the Google() test from the IETest class in the WatiN test project because I had done the equivalent in my own test code when first learning how to use the library. As a side note, this was the first time that I’ve used the Resharper test runner and I was duly impressed (I’ll wait until the next post to share my thoughts on how it compares to other test runners).

Once I get a feel for the style and basic flow of the code through some of the common usage paths, I then find it helpful to use Resharper’s Type Hierarchy window and VS’s Class Diagram to explore the inheritance hierarchies.

The Type Hierarchy window window in Resharper works well when I am in the middle of examining code and want to know more about the classes being used. Several other options under Resharper’s Go To menu, such as Usage, Inheritor, and Base also work well for this type of exploration.

Finally, at some point I usually want to understand the big picture and see how all of the classes relate to each other. In this scenario, the View Class Diagram in the Visual Studio Team Edition really shines. It is especially nice since you can adjust the level of detail you see and then simply jump back into code by double clicking on a class whenever you are interested in a particular member.

Here are a few setup notes to keep in mind if you decide to download and build WatiN yourself:

• I downloaded the 2.0 zip file that contains the source, but the solution file that comes with it appears to still be in a 1.1 format because it prompts you to upgrade the project when you open it in VS2005.
• You will then get a compile error that the name ‘isSTA does not exist in the current context’ because the required conditional compilation symbol is not set in the solution.You will need to add ‘NET20′ to the Conditional Compilation Symbols field on the build tab under the project properties.
• In order to get the Test project to compile, you will need to download the Rhino.Mocks dll and fix the missing reference.
• Depending on which test runner you use, you may find that the majority of tests fail due to the apartmentState not being set to STA, which can be fixed with a config file change.The Apartment Thread needs to be set to STA because WatiN uses COM interop with Internet Explorer.
• If you try to download and upgrade the 1.1 version, the project will have an invalid reference to Interop.SHDocVw because VS2005 has a different wrapper around IE than VS2003. In this case, you’ll need to manually remove the invalid reference and add a reference to ShDocVw.dll from the System32 directory.

Happy spelunking!

In the Agile community, a war room refers to a team room where developers work, customer meetings take place, and all projected related information is displayed. It is supposed to maximize communication and transparency into the health of the project. 

I think one sign of a healthy agile project is evidence of some good fun. These are pictures taken from a war room at the bank where I am currently wrapping up my near six year tenure. These guys have obviously taken the war room to a whole new level.

Update: It turns out that this was a clever prank by Rob. He explains the context in his blog post. Knowing the team, which does like to have fun, I am guessing that they will keep their new little green team members as a permanent fixture of their war room.

Several weeks ago I used WatiN (pronounced as What-in) to create a suite of automated GUI tests for an old internal ASP application that we were upgrading. Inspired by the popular ruby testing tool Watir, WatiN is an open source .NET wrapper around the Internet Explorer that you can reference in your test project and use to get access to all of the HTML elements on a web page. I was surpised by how easy it was to simulate a user typing text and clicking buttons and then check to see if the result page contained certain text. The following popular example code demonstrates how you would test a google search for WatiN.

[Test]
public void SearchForWatiNOnGoogle()
{
 using (IE ie = new IE(”http://www.google.com”))
 {
  ie.TextField(Find.ByName(”q”)).TypeText(”WatiN”);
  ie.Button(Find.ByName(”btnG”)).Click();
  
  Assert.IsTrue(ie.ContainsText(”WatiN”));
 }
}

Today, I experimented with the IEDevToolbar for the first time and suddenly WatiN became much more compelling. By using the “Select Element By Click” feature under the Find menu in the IEDevToolbar, you can simply click on an element on a web page and instantly see all of its properties. Since most popular commercial sites have very large, chaotic source files with elements that don’t always have ID or Name properties, this feature is indispensible when trying to figure out how to programmatically interact with the page. Below shows how I was able to retrieve the Starbucks stock price from CNN and create a test to ensure that it was above an acceptable amount.

Since the stock retrieval button on cnn.com was an image that had no name or ID, I used the Find.ByCustom() method to retrieve and click on the button using the className attribute.

This task would be even easier using the WatiN Test Recorder, which you can see in this flash demo. However, I still haven’t been able to get the recorder to work properly on my Vista machine so I’m not a big fan of this tool yet. I will definitely keep an eye out for future versions though.