Adventures in Agility

 

 

 

 

A while back I did a lot of analysis using data from the Service Factory: Modeling Edition source code control and continuous integration (CI) servers. I analyzed the causes, impact and frequency of build breaks and the cost of using a lightweight check-in process over a more lengthy “complex check-ins that never break the build” approach.

You can read more about the experience report in the proposal “A Hundred Days of Continuous Integration“. I’m really looking for feedback on it so I’d encourage you to review it on the Agile 2008 site (or here if you don’t fancy creating an account on the conference site).

Thanks!

This blog has moved, I cross post here very infrequently. You can read more posts here.

 

This blog has moved, read the full post here.

How do I allow developers to automatically sync to the last known good (LKG) version of the source code? The simplest algorithm for doing this appears to be...

 

 

 

Software development is full of pitfalls. Sometimes it’s the little things that can have you up burning the midnight oil....

So here’s something we ran into the other day while testing installers on Vista. Our installer currently contains delay signed binaries as we don’t do final signing for our nightly builds. We’re installing assemblies in the GAC and running one of them as a custom action as part of the MSI’s installation so before running the MSI we were disabling string name verification for all DLLs signed with our key...

This blog has moved. Read the rest here...

xUnit is the latest greatest unit testing framework from Jim Newkirk, one of the original authors of NUnit. Jim, Brad and the CodePlex team have finally released it on xUnit.net.

 

This blog has moved. Read the rest here...

 

So I'm moving this blog to a new home.

This is part of the hosted site I've been running for while and I wanted everything in the same place.

 

I may continue to cross post here for a while but I suggest you vist the new site and update your bookmarks and feeds.

 

Thanks,

Ade

 

Both the paper and presentation are now available online. 

 

So I've got lots to write about based on conversations I had at Agile 2007 last week but I've been gone from work for nearly six weeks so time is a bit short - lots of catching up to do.

 

Thought for the day...

By this I mean if someone asks "Where's Joe?" the answer should be "Have you tried the team room?", not his office, or call him at home or some other place that isn't the team room. If the most likely place to find Joe isn't in the team room then we're all kidding ourselves that Joe's on the team.

 

This may seem obvious but people seem to find lots of good reasons to be elsewhere. In many cases they may feel that they have no choice. For example they've been asked to contribute to four different projects each of which take 25% of their time. Either way let's not kid ourselves that they're "on" the team.

 

 

 

I'm off to Huaraz, Peru on Monday for a spot of alpine climbing, so there will be no blogging here for the next month. I get back just in time for Agile 2007 in Washington, DC. I'll be the thin and probably very sunburnt guy presenting on Thursday morning. Hope to see you there, it promises to be a great conference!

 

In the meantime a paper I wrote with fellow patterns & practices members Dragos, Wojtek and Jason has gone to press in IEEE Software Magazine. The Growing Divide in the Patterns World outlines some of p&p's experiences with pattern languages and the community at large.

 

So a while back I was given a copy of Raving Fans to read. It's a fable about great customer service that creates "raving fans" the people who can't stop talking about your product or service and how great it is. I have to say I don't disagree with the book. A lot of what it espouses is common sense, some of it even resonates with some values held dear by the agile community, like continuous small improvement.

 

My problem lies with it being a work of fiction. By that I mean it uses completely fictional examples of fantastic customer support to show how you create raving fans. This is all well and good but if I'm going to commit I'd like some evidence to back it up. At the very least the book needs an appendix with some real world examples and references to back it up. Otherwise it's just a work of fiction, all be it one that tries to sell a great vision of customer service.

 

So a while back I blogged about CI and defence in depth. Since then the Service Factory team has had time to start evaluating the results of our latest defence in depth tooling.

 

As a Lead on Service Factory one of the things I'm responsible for is code quality. Obviously the best way to do this is to be in the code as much as possible, writing new features and fixing bugs. What I like is tools to point out where to go and look for issues. Problem areas of the code that deserve my attention.

 

Lots of people use FxCop to check for common programming mistakes as well as to reinforce stylistic and naming rules in their codebase. We've been running this for a while and after an initial drive to get the code passing the majority of FxCop's rules it's proven a good way to add some consistency to the code and prevent those common errors creaping back in. No surprises there. I've been using FxCop for several years and have always had good results from it (see footnote). 

 

So how do you take it to the next level? FxCop's rules highlight cosmetic and localized coding issues. What would be even more useful is to get notified of areas of high complexity, high coupling. NDepend is a tool that does just that. It generates reports detailing things like coupling and cyclometric complexity. You can also write custom queries, for example return the methods with the highest complexity and lowest number of methods (classes with overly complx methods for refactoring) or classes with the highest coupling and most methods (classes what do too much).

 

You can find out more about NDepend at http://www.ndepend.com/. There's example reports to look at and you can download a trial version and run it on your latest build. I can pretty much guarentee it'll tell you some things you didn't know about the code your team has been working on!

 

Currently I've only start using NDepend to look for hot spots in the code; lengthy or overly complex methods, methods with lots of parameters and the like. I'll be blogging more as we start looking at dependencies and comparing changes in metrics with baselines.

  

Note: I've heard people tell me that they don't like FxCop because it give them too many false positives or has rules they don't agree with. I say that's fine. It's easy to customize the tool and turn off rules you don't like. I tend to turn on additional rules over time as I clean up the code. 

 

So it's Friday and I have nothing to blog about.

 

Other than...

So I guess there is a lesson here. If you have to work Friday afternoon then doing so in the nicest teamroom imaginable with the best music you can think of and very few distractions is a pretty good way to do it.

 

 

This discussion has been going around for a while. Esther Derby's post made me think a bit more about it.

 

I'm with her all the way on this. In fact I might go so far as to say I'd actually rather have a team of competent people than a team of extremely competent "stars" - especially people who think they are stars.

 

 

In 1998 France won the Soccer World Cup beating a Brazilian team of "stars" thought to be unstoppable. How, by fielding a team that played as a team.

 

In cycling, in some ways the epitomy of a team activity, Lance Armstrong won his seventh Tour de France because of solid support from his team and because his competitors were unable to attack effectively. Most notably Telecom who's three star riders, Ullrich, Kloden and Vinokourov seemed to spend a lot of effort chasing each other and not putting pressure on Armstrong's Discovery team, even when it looked weak. Lots of "stars" and poor teamwork lost out to a stronger team.

 

 

So Eric Carter and I will be presenting at Agile 2007... Agility and the Inconceivably Large. I'll also be doing something in the Open Spaces sessions if I can get my act together.

 

I attended last year's conference, had a great time and learnt a lot in the process.

 

 

Someone at Microsoft asked for some thoughts on CI…

• I guess my first thought on CI is why would anyone not do it? A CI server takes less than a morning to setup, an hour or so a month to maintain – depending exactly how you use it – and it saves your devs from running a full set of suites and doing buddy builds for each checkin. In my last team this saved us at least an hour per checkin!
• Of all the agile practices CI is the easiest to adopt and provides lots of gain for minimal effort.
• Your CI build should be fast, sub 10mins, and ideally sub 5mins. All it should really have to do is build and run (unit) tests. This is what people really mean when they say “CI” but I rarely do just this.

The concept is too powerful to just leave at that. Here’s some other things I do or have done using a CI server and had success with:

• Don’t be afraid to use you CI as a tool for forcing quality. We’re just about to change our CI build to not build MSIs but to run FxCop instead. Why? We were having a lot of quality issues around our MSI setup breaking, now we’re more worried about introducing FxCop issues. We also wanted to reduce the CI time as it was creeping up.
• If you don’t have lots of unit tests (and of course you should) you can use your CI to run click tests. We did this in when we setup CI for the Visual Studio Tools for Office team and had our CI machine build and run a series of automated build verification suites that launched VS etc. This probably isn’t going to meet your <10mins bar but I’d rather have some tests than no tests. You can also use option #3 below.
• I'm also a big fan of defense in depth when it comes to use of a CI Server. What I mean by this is apply progressively higher bars using the server to drive this. Currently our process looks like this:

1. Devs are “encouraged" to do a clean build and run at least some unit tests locally before checking in. I don’t mandate this but most people don’t like to feel foolish when they break the build.
2. CI build builds on a clean tree and runs tests in a clean environment to catch missing files and other local dev environment related issues. Our CI machine may also do some other things if they are light weight enough; FxCop, installer and setup testing.
3. There would be nothing to stop us having another intermediate build that ran every hour or so and did other, lengthier, tasks around quality. For example I could be running a much larger test suite every hour or so. The name of the game if finding defects as soon as possible, ideally a few minutes after they’re checked in.
4. Every evening we use the same server to build a drop. At this point we do some additional checking around the setup – for example; are all the DLLs being added to setup signed? This build gets sent to QA for testing
5. Every night we run static analysis; FxCop, NDepend and VSTS code coverage which all generate reports.

• You have to promote a culture within the team that CI build breaks are BAD. Nobody checks in when the build is broken and somebody – preferable the person who broke it – fixes the build. Immediately. If you can have your CI server send email when this happens and generally make a stink until it thinks it’s fixed.

Frequency of CI build breaks is a somewhat useful metric for “do my devs have their act together?”. The question “Is it always the same person who breaks the build?” is also interesting in some cases. I’m not suggesting a witch hunt but it may highlight either people who are struggling to understand the overall application architecture, an application with pieces of horribly coupled functionality, or someone who simply needs to be more careful.

A Story… I mentioned my last team (part of Visual Studio Tools for Office) earlier. During Visual Studio 2005 we required each dev to do a buddy build and run build verification tests (BVTs)on each checkin, this would take at least an hour. As we added more BVTs this time grew and we adopted a CI system. The allowed us to remove this requirement, devs would do a local build and run a smaller set of sanity check suites and check in. This practice saved us many hours of dev time.

 

An casual conversation with George, the PM on CodePlex, got me thinking about XP's notion of supporting practices.

 

How does TDD support the notion of shared space? Superficially it doesn't but in fact for me it's really helpful, whether I'm pair programming or working on my own. Inevitably in a team room you have to deal more interuptions than you would if you were working in an office with the door shut. Here's two scenarios that illustrate how TDD helps with that.

 

 

Working on a problem... I have large chunks of the application "assembled" in my head. As I change code I have to remember all the dependencies and what else I might have effected with as I make modifications. I may or may not have some unit tests and the acceptance tests I have might takea while to run. Old Skool in other words.

 

Doing this well requires me to get into a flow state. When things get tricky it can feel a bit like playing chess in your head. When I'm interupted I have to drop the problem and then pick it back up. The cost of doing that is fifteen minutes or more.

 

 

TDD. I'm changing one small piece of code and while this may have lots of dependencies - I have tests around those too. TDD forces me to tackle the work on the problem in a linear fashion and break it into small pieces. The tests ensure I know the state of progress at every step. When I'm interupted the effect isn't as significant because TDD has forced me to serialize the workflow and tackle one small problem at a time.

 

The other things I like to have to hand when doing this are a list of stories - which makes sure I don't forget any functionality during context switches - and a whiteboard or paper diagram of what the application design might looks like. These allow me to pick up on the general direction of work after longer breaks.

 

So Jo Cranford passed me and a bunch of other Agile '06 attendees a blog-tag. It's sort of like a game you might play at parties.

 

So... here are five things that most people wouldn't know about me. This turns out to be a little tricky as lots of stuff about me is already online. Here are a few random bits of trivia:

Most of the people I know who blog are fellow Microsurfs so I'm going to tag Alan Ridlehoover, Peter Provost, Brad Wilson, Eric Carter and the CrossFit Eastside crew.

In the patterns & practices (p&p) group at Microsoft we have been using software patterns for several years. I'm working with a couple of colleagues on gauging how the folks employing the guidance coming out of p&p (such as guides, application blocks, software factories and reference implementations) have, are, and will be using software patterns.

To do that we assembled a short survey, I'm not lying about te short part. If you've used patterns I encourage you to take it. If you haven't used patterns yet but your development tools use patterns one way or another then you could also take it since I'm also interested in your perspective.

You can find the survey Software Patterns: Past, Present, Future here. Thank you in advance for your answers.

http://www.zoomerang.com/recipient/survey-intro.zgi?p=WEB225YFJ8WW6L

 

I was assigned the task of getting a replacement, preferably before The Susan's favorite mid-week shows. No easy task given that the whole of Seattle was shut down by the storm. The solution is pretty obvious. Head to my local big box electronics retailer and drop a couple of grand on a high definition flat TV. Problem. Television just doesn't do it for me. There are things I can get really excited about and televisions just aren't one of them. Climbing gear, bicycles, computers - Nice! These are "toys". Cars, televisions and washing machines are, well, appliances - Boring.

 

So there's obviously something deeply wrong with me. So what. If TV could make itself a bit more interesting or interactive then I might be able to get a bit more excited. In the end I picked up something from Craig's List for a couple of hundred bucks. With everyone else upgrading there's lots of deals to be had. The Susan can watch Prison Break and I can see Heroes - which is at least reasonably interesting, not that the Fall lineup gave it much competition. All is right with the world. Plus I can still say I own a set of climbing ropes that cost more than the TV.

 

Several of my fellow bloggers have discovered this neat toy for creating World and US maps with visited countries highlighted. My effort can be found on my climbing blog.

 

This is really an interesting use of GIF technology. A far cooler peice of mapping technology is Virtual Earth map control. I'v been playing with this and the Windows Live search SDK to add some cool mapping and searching to my climbing site. More on this soon.

 

So for almost the last three years I've been working for the Visual Studio Tools for Office (VSTO) team as a Developer and then more recently as a Development Lead. In that time I've learnt a lot about large scale software development on one of, if not the largest windows application shipping today - Visual Studio. I've also learnt a lot about managing teams. 

 

Recently I had the chance to interview for a role with the Patterns and Practices Team here at Microsoft. They're a fully "agile shop", doing XP in a pimped out custom built space with a multi disciplinary team. Most of the P&P development team are active within the development community promoting agile both inside and outside Microsoft (many of them appear in my blog list). They work closely with enterprise customers shipping application blocks, software factories and other guidance to help them leverage Microsoft's technology offerings around the .NET framework.

 

P&P offe