Adventures in Agility

This blog has moved!

Wed, 23 Jan 2008 23:38:19 GMT

This is truely the last post...

My new blog can be found at:

http://www.ademiller.com/tech/

A hundred days of continuous integration

Fri, 11 Jan 2008 04:01:58 GMT

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.

Gotchas: MSTest test projects don’t load on VS Pro

Tue, 30 Oct 2007 05:31:16 GMT

As is always the way. In the process of writing my last post I found something else that has caught me out in the past.

This blog has moved, read the full post here.

Syncing to the last known good build

Mon, 08 Oct 2007 23:44:17 GMT

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...

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

Gotchas - Using SN.EXE on Vista

Fri, 28 Sep 2007 00:09:07 GMT

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 released

Thu, 27 Sep 2007 05:37:37 GMT

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...

patterns & practices Summit 2007

Wed, 26 Sep 2007 08:23:50 GMT

I’ll be speaking at this year’s patterns and practices Summit, along with a host of other people, including all the usual suspects.

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

We're moving house

Mon, 24 Sep 2007 22:31:16 GMT

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

Web Page: http://ademiller.com/blogs/tech/
RSS Feed: http://ademiller.com/blogs/tech/?feed=rss2

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

"Agility and the Inconceivably Large" is available online

Fri, 24 Aug 2007 00:16:31 GMT

Both the paper and presentation are now available online.

Thought for the day

Thu, 23 Aug 2007 18:26:25 GMT

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...

"If you're not in the team room,

you're not on the team."

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.

Climbing not Blogging

Sat, 07 Jul 2007 18:53:05 GMT

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.

Raving Fans

Sat, 07 Jul 2007 18:45:07 GMT

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.

Continuous Integration, NDepend and Code Quality

Wed, 13 Jun 2007 04:25:29 GMT

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.

Friday

Fri, 08 Jun 2007 23:40:55 GMT

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

Other than...

CNN added further evidence to my claim that I have the nicest office at Microsoft - provided you don't mind sharing!

Peter, the diluded individual who keeps refering to himself as my "manager" has signed up for Twitter. I've already confessed to being a Luddite so I'll leave you to imagine my feelings on knowing Peter's every movement as he trolls around the drunken geek orgy commonly known as "TechEd".

Pixies are still represent one of the best things to listen to in the Team Room. There are bands I like more but my team would kill me if I played them.

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.

Does agile need extremely competent people in order to work?

Tue, 22 May 2007 19:43:37 GMT

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.

I think this applies to other team activities too...

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.

Presenting at Agile '07

Mon, 21 May 2007 17:20:42 GMT

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.

Continuous Integration...

Mon, 07 May 2007 15:42:55 GMT

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:

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.
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.
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.
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
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.

TFS Tricks: Using a different diff tool

Sat, 07 Apr 2007 16:41:33 GMT

For those of you who haven’t fallen madly in love with the default code diff’ing tool in TFS he’s how to use WinDiff or another diff tool with TFS…

“Just go to Tools->Options->Source Control->Visual Studio Team Foundation Server and click on Configure User Tools to specify the diff tool of your choice. Enter "*" for the Extension, the path to your diff viewer's executable in the Command and leave the Arguments as "%1 %2" to hook it up.”

I stole this off someone else's blog - no credit for me - but I thought it was worth mentioning as it's rather buried in the UI. There's a lot more detail here too.

Supporting practices... TDD and Shared Space

Sat, 07 Apr 2007 16:37:00 GMT

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.

#1 - Old Skool

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.

#2 - TDD

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.

TFS Tricks: Reverting unchanged files

Sat, 07 Apr 2007 16:31:56 GMT

So my new(ish) team, patterns and practices, use TFS rather than the internal tool that I used while developing VS 2005. I'm still learning some of the finer points of TFS to allow me to do some of the things I used to take for granted.

One complaint I have with TFS is that you end up checking in a lot of files that you didn’t actually change. While TFS is smart enough to figure this out and not really use any space storing null diffgrams it makes your checkins very noisy. This happens a lot when generating T4 templates for DSLs etc.

Turns out the TFS Power Tool has a command to help solve this problem.

tfpt uu

This will figure out which files are unchanged and allow you to revert them. Remember to hit the Refresh button in the Source Control Explorer to sync the IDE up with changes you made from the shell.

Book List: I'm Reading...

Sat, 09 Jun 2007 03:58:31 GMT

I'm Reading...

Custom List: Shiny Toys

Thu, 30 Nov 2006 06:34:18 GMT

Shiny Toys

Patagonia Micro Puff Jacket
Stay warm, stay light.
Charlet-Moser Quarks
Best ice tool ever. Period.
Mammut Pheonix 8mm climbing ropes
No second chances.
Trek 5000 Carbon '04
Ride until it hurts... ride some more.
Laptop Wireless Mouse
Small, wireless and sooo shiny.
iriver H10 20GB
600 hours of music and radio.
Canon A630
Going digital at last.

Book List: Recommended

Mon, 02 Oct 2006 19:51:12 GMT

Recommended

Craig Larman: Agile & Iterative Development, A Manager's Guide
Good overview of several popular agile processes
Ken Schwaber: Agile Project Management with Scrum
Companion book to Ken's course
Barry Boehm, Richard Turner: Balancing Agility and Discipline: A Guide for the Perplexed
Mark F. Twight: Extreme Alpinism: Climbing Light, Fast, and High
Kent Beck, Cynthia Andres: Extreme Programming Explained: Embrace Change
Niccolo Machiavelli: Machiavelli's The Prince
Brian Michael Bendis & Michael Avon Oeming: Powers, Vol. 1
Who killed Retro Girl?
Katsuhiro Ôtomo: SteamBoy (DVD)
From the author of Akira
Guy Kawasaki: The Art of Start
Start something... anything
Mark Haddon: The Curious Incident of the Dog in the Night-Time
Ever wondered what it might be like to be autistic?
Brian Greene: The Elegant Universe
String Theory 101
Loren Cordain & Joe Friel: The Paleo Diet for Athletes
Eat like a hunter gatherer