I found this nice article today in this month's Agile Chronicles:

Agile Chronicles: Leading Volunteers with Agility

I found it particularly relevant because I am an officer in a club and have often felt that I could better apply some of the agile values to that organization and not just to my work as in software development.

Enjoy!

Recently, I’ve been dabbling with doing TDD in PowerShell. I think there may be a TDD Framework brewing in my head, but at this point I haven't done enough to figure out what such a framework would look like. Often I find that the functions I’m writing depend heavily on built-in cmdlets and BCL types and there can be issues mocking them out when the underlying .NET type isn’t easy to mock out. This isn’t so much an issue with PS as it is an issue with .NET, but since PS is very close to the edge of the world (where the code touches the user), it can be hard to mock.

That said, as with most dynamic scripting evnironments, you can mock out a lot of things. Suppose you want to test a function that depends on get-childitem. Because functions evaluate before cmdlets, you can actually replace it by defining a function with that name:

function get-childitem() 
{ 
return @()
} 

Now you have a naked stub get-childitem that returns an empty array. All is good so far. Next you need a gci that returns a single FileInfoObject and for your test you want to have the “archive” bit set on this file. You try to create a new replacement function for get-childitem:

function get-childitem() 
{ 
$fi = new-object System.IO.FileInfo(“bogus.txt”) 
$fi.Attributes = [System.IO.FileAttributes]::Archive 
} 

But at this point you discover that you can’t set the Archive bit, because the file doesn’t exist.

This is actually a common problem we run into when we TDD up against another API that isn’t mock friendly. In an OO language like C#, I will typically wrap it up in another class & interface that I own and then mock out the interface for my code. This is do-able in PS, but a little more complicated because you may have to implement a fair amount of extra code to create and return a PSObject that has the interface you expect to find in your calling code. (This code can be a lot smaller, but less clear if you want… I opted for clarity):

function get-childitem() 
{ 
$fi = new-object PSObject 
$getter = { return [System.IO.FileAttributes]::Archive } 
Add-member –inputObject $fi –memberType ScriptProperty –name Attributes –value $getter $secondValue $setter 
Return $fi
} 

The challenge with this approach is the amount of code it takes to mock out all of the parts that you need. For example, if you need the Mode script property that comes built in to PowerShell for DirectoryInfo and FileInfo, then you will have to add them to your mock. If you also need to support the setter for the Attributes property, then you will need to add that (and possibly a Note member to hold the data).

As with all mocking exercises, this gets complicated when interacting with real things and since PowerShell is really about interacting with real things, it is hard.

Enjoy!

I've been waiting for them to announce this for a while, but it has finally happened. Jim, Brad and co. have finally released and announced their new unit testing framework for .NET. Here's an excerpt from Jim's post (click thru to read the whole thing):

Announcing xUnit.net

In the 5 years since the release of NUnit 2.0, there have been millions of lines of code written using the various unit testing frameworks for .NET. About a year ago it became clear to myself and Brad Wilson that there were some very clear patterns of success (and failure) with the tools we were using for writing tests. Rather than repeating guidance about "do X" or "don't do Y", it seemed like it was the right time to reconsider the framework itself and see if we could codify some of those rules.

Additionally, the .NET framework itself has evolved a lot since its v1 release in early 2002. Being able to leverage some of the new framework features can help us write clearer tests.

Another aspect of change that we wanted to affect was bringing the testing framework more closely in line with the .NET platform. Many of the decisions we made, which we enumerate below, were driven by this desire. We wanted an architecture which is built specifically for programmer testing (specifically Test-Driven Development), which can also be very easily extended to support other kinds of testing (like automated acceptance tests).

Finally, there have been advances in other unit test library implementations that have not really surfaced in the .NET community.

While any one of these reasons would not necessarily have been sufficient to create a new testing framework, the combination of them all made us want to undertake a new project: xUnit.net.

Jim has been chatting about this for years with Brad Wilson, Scott Densmore, Brian Button, myself and many, many others in hallway chats, at conferences and via email and it has finally happened.

I can't wait to see what people think. Congrats Jim and team!

There was another discussion on the internal agile discussion list that I thought was worth talking about here.

The question was, "How much detail should work items in your product backlog have?"

Eric Gunnerson replied:

It depends on where it is in the backlog.

Items that are just entered and/or are quite a ways out can be fairly general.

Items that are near that top have to have sufficient detail for the team to be able to generate sprint items from them.

To start, I think it’s more important to capture absolutely everything, and then work at doing the refinement as you need it.

And I followed up with this:

+1 from me on Eric’s description.

Basically when something is “way down the plan”, it need be nothing more than a reminder to the person who added it to the backlog. A title and perhaps a description. If they actually have some idea of acceptance criteria then put that too, but it certainly isn’t required. A “T-Shirt size” doesn’t hurt if your team uses such things.

As the item floats up the stack, you need to add more detail to it. Before it can get into a Release Plan (I’m more of an XP-er than a Scrummie), it needs more detail. It may need to get broken down. You will need to think about where it fits in your skeleton architecture. You want to have a sense of what the design might look like.

For it to get through the iteration plan, it needs more information. Better estimating. Clearer acceptance criteria. Etc.

I like to call this “Progressive Rendering”. Everything in agile is about progressively discovering more detail as the detail is needed. It is about doing a thing at the last responsible moment.

At least that's how I like to think of it. :)

Today on one of the internal MSFT agile aliases, a friend of mine asked and answered a question he gets all the time:

How do I become an Agile coach?

He pointed out that you can become a Certified Scrum Master by taking a course, but that you aren't really a coach until and unless you have real experiences to back it up.

I replied to the thread with this...

My experiences mirror yours. But as you point out, not everyone can just go “work with Ward”. ?

Personally, I like this kind of an answer (sports metaphor intended):

You can’t really set out to be a coach without first being a player. Get good at playing your position. Once you are good at that position, take time to learn how the other positions work. Learn how different kinds of people play different positions. Try out other positions when appropriate. Work to learn to think holistically and outside of your own comfort zone. Read a lot. Practice a lot. Talk to coaches as much as you can, and be sure to take it all with a grain of salt.

A coach is someone who can combine theory with their own unique experiences and find a way to use that to lead others to achieve success. To be a coach you have to have good communication skills, so if that is an area that needs attention, work on that too.

Finally, as with so many other leadership roles, it is important to recognize that coach is a recognition that others make of you. You can’t be designated or self-designate yourself as a coach or a leader. When people ask you to come and help coach them, then you are a coach.

Another thing that matters a lot from my perspective is being able to be pragmatic and not dogmatic. But as Shu-Ha-Ri [1] teaches us, sometimes we have to start out following dogma (Shu) to better understand what is really going on underneath it all (Ha) and perhaps if we’re lucky achieve enlightenment (Ri).

[1] More reading on Shu-Ha-Ri: The Aikido FAQ, Alastair Cockburn’s Unknowable and Incommunicable

A while back Naysawn Naderi has posted a series of write-ups of the upcoming features in Visual Studio Orcas (that I forgot to blog about) that are specifically to address the needs of TDD and developer-oriented testing. I was on the committee of people who helped advise their work in this area and while there is still a lot of work to do, they are doing some good stuff that should help:

1. Better Execution Times
2. Run Tests Context Menus
3. Short cut keys to run tests (WOOT!)
4. Disable the "test deployment" icki-ness
5. Support for the Abstract Test Pattern via Test inheritance (boo!)
6. Click thru to the point of failure

Yes, we all know these things should have been there in V1, but they weren't. And now we're trying to make it better.

• Part 1
• Part 2

Grats to Naysawn and team for helping move the ball along.

Introduction

As many of you know, I repave/reformat my computer often. I always used to say that I did it every 6 months, but it seems that it gets more and more frequent as my tolerance goes down and I get better at the repave process. I now can have a full repave done and be back to functional in about 2.5 hours. I can start it, go to a meeting, come back for 15 mins, go to another meeting and when I get back I'm pretty much functional.

Not everything that was installed will be installed, but actually that is the point. Since the 90s Freeware Software explosion, I have loved tinkering with new tools and things. Over time they accrete onto my system. Some I uninstall, some I don't. Some I keep using, some I forget about. Some uninstall cleanly, some don't.

Almost all of them however, leave a fingerprint behind in the registry or the filesystem. And like many people who don't like fingerprints on their computer screens, I don't like fingerprints in my operating system.

A number of people have asked me how I do my repaves this efficiently. There are a few tips and tricks, but none of them are particularly new or surprising. It is essentially an application of agile techniques applied to a non-software problem:

1. Stack rank your backlog and keep it prioritized as you learn more and things change
2. Have clear release criteria so you know when you are done
3. Use good discipline and practices to enable you to respond positively to change

The Process

How these are specifically implemented in my system is as follows.

Stack rank your backlog and keep it prioritized as you learn more and things change

For years, I have been keeping a "log" of the software I install on my system. Every time I install something, I open up the list and add it to the bottom. The list has two sections, "Done" and "Backlog" indicating what has been done and what I think I still need to do. It looks something like this:

Done

[x] Windows Vista 32-bit IT Supported Image
[x] eTrust Antivirus
[x] Restore My Profile from Backup
[x] Office 2007
[x] Configure and run Microsoft Update
[x] Configure Outlook and start First Sync w/ Exchange
[x] Password Minder
[x] ISA Firewall Client

Backlog

[ ] Windows Live Writer
[ ] X-Chat2
[ ] Live Meeting Console
[ ] Vim
[ ] Configure Consolas as a console font
[ ] etc
[ ] etc

Although this log is now a OneNote page, it was for a long time nothing more than a text file on my desktop. When I started a new repave, the first thing I would do is copy the old file over to the new empty desktop. I delete the old Backlog because since they were never done on my last build, it is very unlikely that I need them on this build. I then move the Done list down into the Backlog list and assume that the stack rank is correct since that was the order that I needed them last time.

As I install software or configure settings that I like, I move them up from the Backlog to the bottom of the Done list (or just add them to the Done list if I didn't have them on the last build).

Have clear release criteria so you know when you are done

This one is actually simple: stop when you don't need any more. Do more when you need more.

How this manifests itself is that there are two big "cut lines" that occur. The first cut line is about on par with what I show in the Done list above. At that point, I can do about 75-80% of my job as a manager. When I was doing more active development, my developer tools were immediately after this cut line and above a number of other things. The two major cutlines I had back then were "usable computer" (OS, email, office, etc.) and then "developer computer" (usable + dev tools). As a manager, new tools (mostly internal corporate tools) are in the second list and the developer tools have moved lower down the stack to be installed only when I need them.

Use good discipline and practices to enable you to respond positively to change

This is the part that people really want to know about when they ask me about this, but ultimately as with Agile Software Development, this is the part that enabled you to be agile not the part that makes you agile. (More on that in a later post.)

The specific practices I apply are fairly simple:

• Everything in your Home - Keep everything that you care about keeping between build in your user profile "home" directory (C:\Users\Username on Vista). Don't put anything anywhere else that you need to keep between builds.
• Profile Backups - XCOPY backup your user profile directory to an external hard drive before reformatting your drive. (The XCOPY options you want are "/h /e /y /c".) You can use Robocopy if you prefer, but the command line switches are much more confusing.
• Single Development Directory - I keep all my "side project" source code in a Subversion repository in the sky. On my local system, I have a C:\Dev directory that I keep my working copies in, but I don't back this up other than making sure everything here is stored in a version control system somewhere.
• Program Files overlay on a backup drive - This is a trick Brad Wilson taught me. I keep a directory named "Program Files" on my external drive that has all of the XCOPY-able programs that I like to have on my system. This includes things like Password Minder, HotKeyPlus, PureText, etc.
• User bin directory in my Profile - This is another directory full of binaries, but these are in my profile (e.g. C:\Users\Username\bin) and are typically little command line tools like grep, awk, svn, etc.
• Helpful Setup Scripts - I have a few PowerShell scripts that I have created for setting %PATH%, %EDITOR%, %VISUAL% etc. and for setting up shortcuts to some of the XCOPY-able "Program Files".

Conclusion

I've been living my computing life this way for years now. The specific practices I've used have evolved over time, but the principles and intent have remained unchanged for a very long time. It allows me to test-drive new software, configurations, tools, etc. and if I screw up my machine, I don't care. Repave it.

It also helps acccount for registry and file system bloat. You know what I mean, even the most perfect uninstaller will leave stuff behind. Hopefully very little, but stuff nonetheless. A clean wipe helps get rid of that stuff.

So there you go... an agile approach to maintaining and managing your computer. People often don't believe me, but I can do my repave back to "usable work computer" in about 3 hours, which really helps me feel free to do it more often.

Enjoy!

One of the more popular and commented on posts on this blog was one I made back before joining Microsoft and before VSTS shipped where I tried to start a community push to get Unit Testing into all of the VS SKUs.

Naysawn Naderi (PM for Developer-Oriented Testing in VSTS) recently announced that we have made a major step in that direction by getting this capability into the Visual Studio Pro.

Great work guys!

A week or so ago, Rory Blythe from Channel 9 came by for a visit and an interview with me and Ed Jezierski. We had a great time during this interview and it is now up for your enjoyment (or torture... YMMV).

Enjoy!

Wow. After years of work and headaches, my good friend Jamie Casdale has just announced the version 2.0 RTM version of TestDriven.NET.

It has always had a great feature set:

• Right-click and run the tests found in classes, fixtures, projects, solutions, etc.
• Run in the debugger
• Run w/ external runner
• Test failures go to Output window and Task list
• Double click on test failure and go straight to the failing test code
• Configurable key bindings for even easier running of tests

And now adds some very cool new things:

• Code coverage – NCover + Team Coverage
• Reflector support – 'Go To Reflector' functionality available on the Code, Disassembly, Call Stack, Modules, Project References and Solution Explorer windows.
• Repeat Test Run – Redo whatever test-run you did last

But I can't really do it justice, so check out Jamie's post. It has better descriptions, screenshots, and more.

Go get it! Come on... you know you want it.