I just noticed that Jamie Cansdale has released v2.0 of TestDriven.NET.  The screenshot are of the new functionality are looking pretty damn cool.  I'm downloading as we speak.

Today I found this new set of addins for VS 2k5 thanks to a post by Greg Duncan.  According to the official Microsoft download page, these "...are a set of Visual Studio extensions provides tools to effectively use Visual Studio resources."  To tell you the truth, I'm really not sure what the hell this is supposed to mean so, as a public service, I'm going to translate that for you. 

Visual Studio 2005 IDE Enhancements are addins that provide new functionality that developers can use to increase the capabilities of the development environment.

I can hear you saying "Enough of that already.  Tell me what the hell it is."  Okay, fine.

Source Code Outliner : The Source Outliner tool is a Visual Studio extension that provides a tree view of your source code's types and members and lets you quickly navigate to them inside the editor.

Visual C++ Code Snippets:The Visual C++ Code Snippets tool lets you insert snippets in your code by using a pop-up menu that contains programming keywords. VB.NET and C# languages have this functionality in Visual Studio 2005.

Indexed Find : The Indexed Find tool is a Visual Studio extension that uses the Microsoft Indexing Service to provide improved Search capabilities to the integrated development environment (IDE). It sends the results of a search to the Output Window.

Super Diff Utility: The Super Diff Find tool is a Visual Studio extension that compares text files. It uses color coding and graphics to show the difference between the files in deleted text (red), changed text (blue), inserted text (green).

Event Toaster Utility: The Event Toaster tool is a Visual Studio extension that notifies users about specific events within the Visual Studio IDE.

I installed the download and worked with it all day today.  First let's say that I didn't see the VC++ Code Snippets, but I'm going to assume that they work like the other Code Snippet functionality in VS and that is cool.

Source Code Outliner is a great little tool.  I had it sitting as a tab in my right side docked windows (Project Explorer, Class Explorer, etc.) and it saved me a bunch of time searching for things.  When you open a piece of code, you get a refreshed view of the currently displayed class in the Outliner.  You can filter the Outliner so it only shows Properties or Methods or Private Variables or...or...or...the list is quite long, but it's great.  It's quite responsive to changes in the code, but it does tend to flicker when it is updating, which I found to be distracting.  Overall, great tool.

Indexed Find is another way to search in your code.  You already have Ctrl+F (Find) and Ctrl+Shift+F (Find In Files) and I really couldn't see what it added to my already extensive searching capabilities.  If anything, I find the Ctrl+N (Type By Name) shortcut in ReSharper to be much more useful.

Super Diff Utility is quite aptly named.  It integrates very nicely in the IDE for things like listing open files in dropdowns on the search selection screen, but it doesn't have a shortcut key.  Once you do get it open there are some amazing configuration choices in it.  I was very impressed with this tool.  It will now be my default comparison utility when I'm in the IDE.

The Event Toaster Utility simply baffled me.  First, the explanation of what it does on Microsoft's site is not overly descriptive.  Please tell me what "...specific events within the Visual Studio IDE" trigger the toaster.  I need to know since nothing I did today made it launch a piece of toast.  Instead all I got was a nice little toaster icon in my system tray for the duration of my development effort.

Overall, this is a nice little set of tools.  Definitely download it and take them all for a test drive.  If you figure out how to launch a piece of toast, let me know.

Sometimes I get scared of myself when I start drinking and posting.  Today I felt a little better when I saw that Michael Arrington and Robert Scoble did the same thing.  Even better is that they drink the same bevy as I do when posting.

First let me say that I am not a tester, let alone a test manager or a testing guru.   What I'm writing here is the out-of-scope ramblings of a developer.

I've been on my new project for about a month now and I'm seeing some shocking trends.  The most egregious is that past releases of the code have gone straight from the hands of developers to UAT (business users in our case).  Now, towards the end of the first major phase (not the first iteration by any stretch) of the application's development, management on the project and from the client is quite concerned about the quality of the software being released.  My first reaction to this was "Well, wft do you expect?".  Now that I've had a few weeks to think about it, here's where I'm at.

We all know that software developers (or programmers or whatever the hell you want to call yourself today) are notoriously horrible testers.  We're far to close to the technical implementation to be able to clearly see the application in the same light as an end user.  Because of this every developer will miss things that a business user would do the first time they sat down and used the system.  Because I'm not actually coding anything on this project yet, I consider myself, and the couple guys I have working with me (all of us have less than one month with the project), to be business users of the existing application.  We were tasked this week past with doing what I'll call usability testing for the majority of the application.  Like true business users, we jumped in head first and within minutes our pod was buzzing with conversation about what we, the business users, felt were blatantly obvious application faults, system inconsistencies and flat out confusion incurred by the way the system interacted with us.  The most frustrating thing for me was that this system had been in UAT for months (I don't know for sure, but my guess is 6 or more months) and we were still having these problems. 

Why hadn't they been found and fixed by the developers?  They're too close to the code to use it like we did.  Also, they've been told to prioritize on a small subset of the application and fix all the Critical and High defects, while we were testing the areas of the application that they weren't focused on.

Why hadn't they been found by the UAT team?  I'm not sure how big the team is, but I have a feeling that they're swamped with the size of the application and the volume of retesting because of defects that they are raising.

Great, I've figured out that the application's quality is substandard and that the client has every right to be pissed at the team.  How do you fix it?  I think that there are a number of ways, and to the credit of my team's management, some were being implemented prior to my arrival. 

First, I believe that you need a dedicated test team to stop the obvious defects from being shipped to the client.  Often this group is called QA because their job is to ensure that a certain level of system quality is met prior to the business users working with it.  Test/QA teams are an insurance policy on the goodwill that you need, and hopefully have, between the development team and the client.  Like other kinds of insurance, the cost of insurance goes up when the size of the object, in this case the application development effort, increases.  This means that tester-developer ratio is important.  If you measure success based on some metric involving the number of defects raised by the business, the most successful project I've worked on, at it's peak staffing, had a ratio of approximately 1:4.  The project I'm on now currently has a ratio of approximately 1:8.  My mathematical way of thinking says that my QA insurance is only going to be half as effective on my current project.  Ratio isn't everything though.  I could try to staff a team with a 1:1 ratio and it may not offer any more benefit than if I'd staffed it with a 1:4 ratio.  There is a point of diminishing returns and a project needs to figure out where that point lies for them.  If you're completely swamped defects, your ratio probably isn't high enough.

Well, now I've put all the pressure for the success and quality of the product, along with the responsibility for the goodwill between the team and the client, on the QA team.  It's time to take some of it off their shoulders.  I'm a Lead Developer on this project.  My job description says that I'm partially responsible for, and I'll paraphrase here, the project being on time, on budget and quality.  Even if this weren't written in stone (we use MS ShareRock v1.0 -- it's buggy, but I think that we just need to upgrade to a better chisel), I'd still be preaching these three points.  The one that is most important for this conversation is quality, and if I'm partially responsible for it, I need to take steps to increase the quality and decrease the defects and defect churn.

From what I can tell, the project I'm starting on hasn't had any concern with quality at the developer level.  Instead they've worked with the mantra that "bugs come in, developers fix them and ship them out to UAT".  As a Lead Developer, I have the responsibility to ensure that the work being done by the other developers is being effective.  This means that I need to do checks, or, as they're better known, code/functionality reviews before anything, defect, new coding or otherwise, makes it to any level of testing.  For me, the question isn't if you should be doing code/functionality reviews, but instead how often are they necessary.  If your project is completely swamped with defects, you need to increase the frequency of code/functionality reviews at the Lead Developer level immediately.  Don't be like my current project has been doing in the past.  Their definition of a code review was a once a month meeting of all the developers where one developer picked a single piece of code that they'd written and presented it.  So the project is swimming in a sea of defects, some of which are continually churning, but code reviews are held extremely infrequently.  It doesn't make sense to me.

Every Lead and Senior Developer out there is fuming right now because I said that they may need to be spending more of their time reviewing and testing the code of other developers and, ultimately, spend less time coding themselves.  You have an incentive to change that...increase the quality being turned out by the team you're working with.  Instead of spending that one meeting a month on a code review with the whole team, spend it on a training session for the whole team.  Work on increasing the skills of your team everyday.  That may include everything from a formalized training session to a solid pair-programming experience.  Take every opportunity to teach the team and you will start to see quality of their work increase.  The other, and in my mind more important, way of increasing quality at the developer level (this includes lead and senior devs too) is to instill a culture that focuses on quality.  The first thing that every developer on your team should think about is quality.  This is one of the things that I'm working on right now with my team.  Everything time I talk about what we are or will be doing, I emphasis the importance of quality to it.  I want my team to have such a high pride of ownership in their individual code and the overall application that they are collectively embarrassed by defects and motivated to resolve them. 

I'm currently seeing an attempt by my team's management to reward people for fixing defects.  There are numerous reasons that this backfires.  The one that I'm most worried about is the fact that it emphasizes individual quality instead of team quality.  I have my ways that I'm going to fight this, but in the end it will be my team that gets the congratulations, rewards and attention if we do a good job on quality.  It won't be me for leading them.  It won't be Joe for fixing the most defects.  Quality is a team effort and thus should be recognized in that way.

So, to wrap up this rather long bit of rambling, I'll list the things that I think are important for improving the quality of the application that you release to your clients.

• Developers don't make good testers.  Because of this, don't rely on them to do your only testing.
• Think of QA as insurance for the goodwill between you and your client.  Make sure you have adequate insurance.
• Quality should be a way of life for developers of all levels.  Make an effort to help them increase their quality.
• Quality is a team sport.

I have no idea where I managed to find this tool.  Regardless, I finally got around to having a go with it.

Tree Surgeon is a .NET development tree generator.  Just give it the name of your project, and it will set up a development tree for you in seconds.  More than that, your new tree has years worth of accumulated build engineering experience build right in.

Like the quote from the website says, all you need to do is name your project and the tree gets created.

As you can see from the image it creates a structure, but what you don't see is that there are files in those folders.  The folders in the src folder contain solution, project and CSharp files.  The tools folder is the great one.  The N* folders that it contains all have those application's files in it.

My only complaint, and it's a minor complaint, is that the solution that is created is for Visual Studio 2003.

Here in Alberta (and one could also say all of Canada) there has been one amazing constant in the MS developer world, Dan Sellers.  I have never had the privilege to have met or be taught by Dan, but I've heard about him from a number of different people who have done both.  Dan was a stalwart in the MS Security community here and when people said we need help with security, the name Dan Sellers invariably was mentioned in the next breath.

Dan announced today that it was his last day with Microsoft.  Thanks Dan for all the things you've done for the community and developers.  Best of luck in all your journeys to come.

One of the things that I'm working on as part of my new job is the creation of a Coding Standards document.  This is an interesting prospect as the software has already been developed for a significant number of months, resulting in a sizable existing codebase.  Writing a coding standards document in this situation is not about creating a fresh new way of doing things, but instead it involves a lot of code review and deciding what have the unwritten defacto standards been thus far.

Part of the reason for creating this document is to empower the developers to enforce their own consistency.  One of the other reasons is to have a document that the Team Leads can point to when they're performing code reviews and enforcing standards.  In my experience, following naming conventions and other coding standards can become second nature, but everyone has moments where they just slip up and a standard gets broken.  What I wanted to be able to do for our developers was offer them an easy, unobtrusive way to review their standards adherence.  I think I found it.

I was out on and about on the web and I stumbled across Joel Fjorden's blog.  Joel has been writing a CodeStyleEnforcer add-in for Visual Studio.  He's leveraged the add-in capabilities of DXCore from Developer Express to integrate the tool seamlessly into the IDE.

Installation of the tool was a breeze.  First download DXCore, then download the DX_CodeStyleEnforcer.dll file from Joel and copy it to the following path.

C:\Program Files\Developer Express Inc\DXCore for Visual Studio .NET\2.0\Bin\Plugins

After that all you have to do is start the IDE and the add-in will be functioning.  All the rules for the Code Style Enforcer are enabled either through RegEx (for naming conventions) or checkboxes (valid visibilities).  This gives you a number of options for customization, assuming you can write the RegEx expression that you need.

 By default the Name Rules are pretty basic.  To test the ability for the application to be customized based on my newly written tome on coding standards I customized them to what you see in the pictures.  The first thing that I did was change the Field Names and Readonly Names to switch them from an 'm_' prefix to a '_' prefix.  After closing the window the code in my IDE was updated to show that it now met the standard.  I also changed the Name Rules to allow for Class names to use alpha-numeric instead of just alpha, and restricted the numeric values so that they couldn't appear as the start of the Class name.  Below is a screen shot show the code using these standards and the unobtrusive reminder (red pencil mark underline) that you have not met the naming requirement.

I did notice one problem with the add-in, but I'm not sure if it's related to the DXCore tool, or the Code Style Enforcer.  When I used snippets and in a some other cases, the proper formatting of the newly inserted code from the snippet was not correct.  Usually this was immediately noticeable as the code did not indent correctly.  Other than that small issue, this is a great tool and I'm going to be working with it a lot more in the future.