Richard Banks - Agile and .NET

How To Prevent Visual Studio 2012 ALL CAPS Menus!

2012-06-01T11:45:00.001+10:00

For all those people who can’t stand the ALL CAPS menus in Visual Studio 2012 there’s a way to switch them to normal casing.

Crack open your registry editor and create the following registry key and value

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General\SuppressUppercaseConversion
REG_DWORD value: 1

Here’s what it looks like BEFORE

And here it is after the change

You’re all very welcome! Now go tell your friends

Visual Studio 11 First Look Cookbook

2012-04-18T11:33:00.001+10:00

I know I’ve been a little quiet lately, but with good reason; I’m writing a book :-)

http://www.packtpub.com/microsoft-visual-studio-11-first-look-cookbook/book

Short, sharp and to the point, and affordable as well! I’ll post more details as the publishing date gets closer, but there’s nothing stopping you preordering a copy now and helping me feed my starving children!

I’m not the only one…

As it turns out, there are a number of other Aussies also writing books at the moment. You should also have a look at what they’re offering and support Australian technical authors.

David Burela just released his Silverlight 5 & Azure book: http://www.packtpub.com/microsoft-silverlight-5-enterprise-integration-on-windows-azure/book

Luke Drumm is currently finishing an XNA 4.0 book: http://www.packtpub.com/microsoft-xna-4-0-game-development-cookbook/book

Alex Mackey, Mahesh Krishnan & William Tulloch are writing a .NET 4.5 book: http://www.amazon.com/Introducing-NET-4-5-Alex-Mackey/dp/1430243325

What do I do With Partially Completed Stories in Scrum?

2012-03-15T22:16:00.001+11:00

It’s not that rare an occurrence for a scrum team to get to the end of a sprint and find that they have one or more stories that don’t meet the definition of “Done!”.

Question

This week from one of my former Professional Scrum Master students asked me about this situation:

”What should we do with un-done work at the end of the sprint?
I was thinking we have two options:
1) Move the user story to the backlog for re-prioritisation (maybe into the next sprint). The problem here is that I’m not sure what to do with the story points as it screws up our sprint velocity
2) Split the user story. In this case we would leave the old user story’s points as-is, then create a new user story with the remaining work and re-estimate with planning poker.
I was reviewing the scrum.org scrum guide and it doesn’t seem to have any details in this area.”

Answer

The lack of detail in the scrum guide should be enough indication on the approach to take. If the scrum guide doesn’t talk about splitting stories then it’s probably reasonable to assume you shouldn’t do it :-)

Putting the story back on the backlog for reprioritisation. Sure, you won’t get any credit for the story in the current sprint because it’s not done, but it won’t screw up velocity either because velocity will be a true reflection of what you actually delivered during the sprint. We want velocity to measure our rate of delivery not our effort. On average, over a number of sprints the velocity figures will average out in any case. So yes, you may well have a few peaks and troughs when looking at single sprints but looking across the last 3 to 5 sprints you should have a good reflection of your actual rate of progress.

Not having a story finished and getting no credit for it also gives the team something to talk about during the retrospective. “Why didn’t we get to ‘done’ on story X?”.

On the flip side, I don’t like splitting incomplete stories because

1. it gives teams an “out” for not finishing properly and they get credit for effort not delivery. It stops them pushing for a goal and stymies the inspect and adapt process.

2. how do you actually split the story that was almost finished? Can you split it in such a way that the work that was “almost” finished meets the “done” definition? Can you do it in such a way that your product owner is absolutely sure that the completed part of the story is Done and that their acceptance criteria are satisfied? Can you cleanly separate the business value delivered between the completed part and the incomplete part? I doubt it.

Taking an incomplete story and splitting it just to make it look like you have a stable velocity reduces transparency and hides the truth of what you can actually achieve from your product owner, your stakeholders and most importantly yourselves. Don’t do it.

The Visual Studio 11 Interface, With More Metro

2012-03-04T18:05:00.001+11:00

Without getting into the “It sucks! No, It rocks!” debate about the new user interface there are some areas that people are particularly fired up about, including the use if colons as a placeholder for menu bars.

On the Visual Studio User Voice site there’s a request to tweak the UI and go “all in” with the Metro styling borrowing from the Zune interface (an interface I happen to particularly like).

Let’s have a look at the current UI as posted on the Visual Studio teams blog entry Introducing the New Developer Experience:

Now let’s look at the proposed user interface with it’s makeover (via http://i.imgur.com/Dh0zV.png):

Not to be left as the sole alternative, here’s a slightly different take on it (via http://i.imgur.com/EWH1R.png)

I’m not campaigning for votes for the feature (and at this stage the UI is going to be mostly set in stone in any case), but what I do want to do is point out that a consistent focus on the Metro design principles makes a difference.

If you go Metro, go full metro, not some halfway house. The alternate user interfaces work in that they remove as much window chrome and scroll bar noise as possible, letting developers focus more on the content and they realise that if typography is king, then make typography king! Fix menu fonts, title fonts, and so forth and be consistent about it. By improving the typography they also managed to retain the shouty tab names in such a way that they don’t grate anywhere near as much as the current UI does. The UI also feels cleaner because the ::::: lines aren’t there adding unnecessary noise.

It’s interesting to see how much of a difference the Metro design language can actually make to a user interface, and definitely something to consider if you get asked by your users to create a Windows 7 or desktop application that feels like a Windows 8 Metro style application.

How To Unit Test Async Methods with MSTest, XUnit and VS11 Beta

2012-03-04T09:10:00.001+11:00

MSTest finally got some love with the Visual Studio 11 Beta and one of those changes was to enable tests to run asynchronously using the async and await keywords.

This is required if you want to write tests against any async methods (especially with WinRT!) but can also be used anywhere else you need to perform asynchronous operations.

Here’s a silly sample test to show you how it’s done

[TestMethod]
public async Task LoadGoogleHomePageAsync()
{
    var client = new System.Net.Http.HttpClient();
    var page = await client.GetStringAsync("www.google.com");
    Microsoft.VisualStudio.TestTools.UnitTesting.StringAssert.Contains(page, "google");
}

XUnit also supports this option as shown here:

[Xunit.Fact]
public async Task XUnitAsyncTestMethod()
{
    var c = new System.Net.Http.HttpClient();
    var result = await c.GetStringAsync("http://www.google.com");
    Xunit.Assert.Contains("google", result);
}

Be aware that if you have a testsettings file specified in the Unit Test Explorer that async tests will not work. This applies to the beta only. Apart from that everything works as expected.

Git-TFS Presentation at the 2012 MVP Summit

2012-03-03T20:43:00.001+11:00

The day before the 2012 Microsoft MVP Summit kicked off in earnest there was an MVP-to-MVP day. For those of us in the Visual Studio ALM area we had a day long series of lightning talks about all sort of TFS related subjects, making for a good and wide-ranging day.

For something different, I did a talk about git and TFS integration and how git-tfs can be used to hide many of the problems with TFS source control. Below is a slightly modified version of the slide deck I used.

I hope you find it useful.

Git TFS

View more PowerPoint from Richard Banks

Improved Unit Testing with Visual Studio 11 Beta

2012-03-03T19:59:00.001+11:00

There’s just so much new stuff in the Visual Studio 11 Beta! In fact, someone should write a book about it… Oh wait, I am! (more on that when the time is right). For now, let’s have a look at one feature that makes me so very happy: Visual Studio’s new and improved unit testing capabilities.
It’s widely recognised by those with a desire to do unit testing that there are better unit test frameworks out there than MSTest but given that Visual Studio has always been so tightly coupled with MSTest it’s always been more difficult than it should be to get other test frameworks working well in Visual Studio. The TestDriven.NET and ReSharper test runners have helped, but the integration back to visual studio was always lacking.
That all changes with the Visual Studio 11. Now it’s a case of “Use the framework that makes you happy. We don’t mind”.
You want to use XUnit? No problem!
NUnit? Easy!
MSTest (without the baggage it usually has)? Sure thing!
QUnit for JavaScript? Bring it on!
Something random that we’ve never heard of? Write an adapter and it’ll work just fine!

Dogs and Cats Living Together!

Visual Studio 11 introduced a test adapter model so that any test framework can run inside Visual Studio if there is an adapter for it. The adapter model also means that you can not only run XUnit, NUnit, or any other type of test but you can run them in the same test assembly if you really wanted to! Why? I don’t know! But you can :-)
Maybe you have a suite of MSTest tests but you also want use XUnit’s data driven test features because MSTest sucks for unit testing. You can do just that. It’s really nice.
Note: In MSTest’s favour, in this release when MSTest is used in a plain old class library for unit testing the MSTest test adapter uses a cut down, light weight version of MSTest with just the features needed for unit testing and none of the baggage that it normally comes with, making it quite usable for most unit testing needs. For most developers with an existing investment in MSTest tests they will see an improvement in performance as a result.

Pre-Requisites

Get yourself started by loading the appropriate adapter for your unit test framework from the Visual Studio Extension Manager. MSTest is already in the box so you don’t have to worry about that one. In this screen shot I’ve loaded up the XUnit, NUnit and Chutzpah test adapters.

Running Unit Tests

Create a new C# Assembly project (NOT a test project) and add the XUnit and NUnit test frameworks to your project using NuGet

You can also add a reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework so that you can do MSTest based unit tests.
Here, I’ve started by adding a simple XUnit test, then building the code and running the unit test as shown:

As you can see in the output window there is now a “Discover test started” phase where Visual Studio looks at the assemblies and determines what tests are in the system so that it can spin up the right framework and execute the tests.
The Unit Test explorer on the left shows the tests that were run, the time it took and any error information for failed tests.
In the same code I have then added MSTest and NUnit tests as shown, however at this stage I have not yet built the project – take note of the unsaved changes icon in the document tab, indicating that the project is neither saved nor built as yet:

Run Tests After Build (Almost Continuous Testing)

Continuous Testing is the idea that as you do your work all the unit tests are constantly running in the background and giving you live feedback when there are problems code by highlighting where tests have failed and where your code is broken. The immediate feedback cycle makes test driven development an even faster development process since there’s no waiting around for all the tests to run.
Visual Studio has taken a step towards this ideal with the “Run Tests After Build” option as shown in the image below. Turn that setting on and as soon as you compile your code Visual Studio will run the tests automatically on a background thread so that you don’t end up with a blocked UI and can get on with coding the next thing on your list.

If a test failed the unit test explorer goes red and it’s obvious that there’s a problem. The interesting thing is that in smaller projects the tests often run so fast that you don’t even notice them happening!

As a tip, once you’ve been using the test after build feature for a while you will probably want to stop the Output window from popping up every time you build so that you don’t have to keep closing it. You can do this in the Visual Studio Options as shown

Don’t Forget JavaScript Unit Tests!

OK, I won’t. Make sure you have the Chutzpah test adapter Visual Studio extension installed (see above).
In a standard web project include QUnit or Jasmine in your project and then create a JavaScript file for your tests. Once you have your tests written run them as you normally would and Chutzpah will do the tricky work of finding the tests and running them. Here’s a screen shot of a web project with a QUnit test in it

Conclusion

So there you have it! A brief overview of the new unit testing features in Visual Studio 11 Beta. Go and get it now and start playing with it.
Having Visual Studio automatically running your tests each time you do a build will change your development workflow for the better and keep you more focused on coding and help you stay in the mythical zone if you ever get there.
Remember that since all tests run in the background and this removes the time spent waiting for tests to finish that you can have tens of thousands of tests taking minutes to run each time and you won’t even feel a delay in your development activities. Fantastic!

Why do Developers Underestimate

2012-02-04T21:38:00.001+11:00

There’s a very funny response to a question on Quora doing the rounds at the moment. The question is “Why are software development task estimations regularly off by a factor of 2-3?”

The response (go ahead and read it) makes an analogy to hiking from San Francisco to Los Angeles to visit friends, underestimating the distance, terrain and rate of progress as well as encountering a number of impediments like the weather, colds, blisters and so forth. It’s a really good read.

It was mentioned on the Australian Alt.Net mailing list, this week and followed up with the question of “so what do we learn from it?”

Two simple lessons come to mind.

Lesson 1: It takes time to produce a reasonable estimate

On any reasonable project don’t expect to be accurate if your estimate takes you less than 5 minutes to arrive at. In the example, it’s pretty obvious that little time was spent coming up with the estimate for how long the hike might take. Once they’d decided they were going to hike, taking time to estimate how long it would take was just stealing time from actually hiking!

As developers, we allow ourselves to do this all the time. “I like to write code, I don’t like to estimate. If I get the estimate done quick then I can get back to doing what I like.”

Stop it. You’re only storing up pain for yourself down the track.

Lesson 2: Think about what might slow you down

When you estimate think about what might slow you down. Very few teams do this but it’s critical if you want to be more realistic about how long something will take.

Most developers estimate with the same approach that they test their own code. They only consider the happy path.

You can hear them in their heads saying “It takes this long to do that. And that long to do that. And … then put it all together and the estimate is X months!!”.

Very few developers then say, “so the baseline is X months. Now what is likely to slow us down?”. Yet there are so many things that can do just that.

Want a basic list? How about the following:

Have you done anything like this before? How vague are the requirements you have at the time of estimating?
How well do you know the technology you’re using? Or the design and techniques you’ll be implementing with?
How well do you know the people on your team? Are you all co-located? Can you communicate easily?
Does your team have all the skills you need to get the job done or will you have to rely on other’s being available?
How well do we know the problem you’re being asked to solve?
How well can you communicate with your customer(s)? How available will they be?
How bad are the worst people on your team and how much will they slow everyone down?
How’s team morale? Are people likely to leave mid project and take a whole lot of knowledge with them? How long would it take to replace them and get them up to speed?
How sucky is the code you’re working on?
How likely is it that people on the team will get pulled off on to other work? And how often?
If you’re estimating will you be doing the work? Or are you estimating on behalf of someone else without involving them?

That’s a starting list of things all teams should consider when estimating and all of those items should be used to take your “happy path” estimate and adjust it from there.

So next time you need to estimate something, keep these two simple lessons in mind and good luck!

Parameters: You’re Doing It Wrong!

2011-11-24T10:39:00.001+11:00

Having parameters for a method is perfectly fine however like anything, they can be used for evil. So let me give you a tip: If your code looks anything like this method signature (and I kid you not, this is a real method) then YOU”RE DOING IT WRONG!

SaveContentSetItem(ContentSetItem,String,String,Int32,Int32,Int32,Int32,DateTime,DateTime,DateTime,DateTime,
    DateTime,DateTime,DateTime ,DateTime,Boolean,Boolean,Boolean,Int32,Int32,Int32,Int32,Int32,Int32 ,Boolean,
    Boolean,Boolean,Boolean,Boolean,Single,Boolean,Boolean ,Boolean,Boolean,Boolean,Boolean,Boolean,Boolean,
    Boolean,Boolean ,Boolean,Boolean,Boolean,Boolean,Boolean,Boolean,Boolean,Boolean,
    FileLocation,String,Stream,String,FileDisplayFormat,Boolean,Stream)

Please, for the love of all things good, turn off your computer right now. Pack it in a box. Put the box in a locked safe. Put the safe in a bunker under a mountain. Seal the bunker using 40 foot thick concrete and collapse the entrance. Place a minefield and barbed wire around the bunker, and never EVER WRITE A LINE OF CODE AGAIN!

Ready Player One

2011-11-23T11:01:00.001+11:00

I wouldn’t normally mention a fiction book here as your taste for books is likely to be different to mine, however in this case I’ll make an exception. I’ve just finished reading “Ready Player One” and enjoyed it so much I read it in just 2 days whilst catching planes and trains and by skipping on sleep. It was such a good read I simply couldn’t put it down! I loved it!

Why so? Because it’s a near future, sci-fi book with a big virtual reality/gaming element that I think most geeks will love, especially those who know what an easter-egg is and those with a good knowledge of 80’s geek-, gaming- and/or pop-culture. Plus it’s got some seriously fun puzzles to try and solve before the reveal happens.

This book was also Amazon’s book of the month for August 2011, and deservedly so. Here’s the Amazon review quoted verbatim:

Amazon Best Books of the Month, August 2011: Ready Player One takes place in the not-so-distant future--the world has turned into a very bleak place, but luckily there is OASIS, a virtual reality world that is a vast online utopia. People can plug into OASIS to play, go to school, earn money, and even meet other people (or at least they can meet their avatars), and for protagonist Wade Watts it certainly beats passing the time in his grim, poverty-stricken real life. Along with millions of other world-wide citizens, Wade dreams of finding three keys left behind by James Halliday, the now-deceased creator of OASIS and the richest man to have ever lived. The keys are rumored to be hidden inside OASIS, and whoever finds them will inherit Halliday’s fortune. But Halliday has not made it easy. And there are real dangers in this virtual world. Stuffed to the gills with action, puzzles, nerdy romance, and 80s nostalgia, this high energy cyber-quest will make geeks everywhere feel like they were separated at birth from author Ernest Cline.--Chris Schluep

That review made it sound a little formulaic and it could easily have fallen into that trap, but blissfully it doesn’t. It’s a fast paced, highly entertaining, well written book and my inner geek loved each and every bit of it, especially the retro 80’s references; from Devo to AC/DC, Dungeons and Dragons to Car Wars (awesome!) and from Ferris Bueller to Family Ties.

As a bonus, this is Ernest Cline’s debut novel. If he keeps up this level of writing or, even better, improves then I can’t wait to see what he comes up with next!

P.S. In the interests of full disclosure I’ve got no affiliations with the book or author and I get no kickbacks for mentioning this book, though I wouldn’t mind if there were some, hint, hint!

If you haven’t read it, go grab it (just a suggestion) and if you have, did you enjoy as much as I did?

Underscores in Test Names are a Pain to Type, Right? Not Anymore!

2011-11-11T08:49:00.001+11:00

It might be a large assumption given some of the customers I deal with, but I’m going to assume you write unit tests. I’m also going to assume that when you write tests your test names have underscores separating all the words and making your test names human readable. Something like This_is_a_really_long_test_name_but_thats_ok_because_its_easy_to_read_when_I_use_underscores.

The only (minor) problem I have with this approach is that underscore isn’t the easiest key to type. I’d rather just hit the space bar and have Visual Studio change that space to an underscore for me – after all, that’s exactly what computers are good for :-)

Here’s the good news, there’s a great little ReSharper macro that has been developed that does just that – it’s available from https://github.com/joaroyen/ReSharperExtensions and all you need to do is create an R# live template that wires the macro up to your test name field in a live template. For example:

Now when you use the live template to create a test you can simply type the test name with spaces and they’ll be converted into underscores for you automagically. Fanstastic!

Kudos to Joar Oyen for his great work, and feel free to check out his blog post for how this works under the hood.

Scrum is Open for Extension and Modification

2011-10-10T14:52:00.001+11:00

The title says it all really.

Modifications to the framework need to be approved by Ken Schwaber and Jeff Sutherland (co-creators of Scrum), and to be honest there are likely to be very few, given it’s such a simple framework.

The more interesting thing to keep an eye on will be the Extensions. As a Scrum Coach and Trainer, I’m often asked what teams should do in a specific scenarios. Scrum is silent on those situations because they aren’t generic enough, and yet there are generally accepted, healthy behaviours teams should have in those situations. That’s the essence of an extension. The healthy, beneficial practices team can use to complement Scrum to help teams in Situation X.

This a is great move by Scrum.org and a very welcome one!

Scrum Extension Library and Submission Guide

Scrum Modification Submission Guide

Australian Alt.NET Open Spaces – Tickets Available

2011-10-10T09:46:00.001+11:00

The inaugural Australian Alt.NET Opens Spaces unconference is happening on Sat Dec 3 in Melbourne, directly after the Melbourne YOW! event.

(Free!) Tickets are now available.

And for the curious amongst you, the famous Seattle Alt.Net conference is run in exactly this style, and has the motto of “practice don’t preach” to indicate that it’s all about participation. Have a search for people’s thoughts on the conference and you’ll invariably find people who found the conference much more enjoyable that traditional lecture style conferences.

So what are you waiting for? Go and book a ticket! I’ve got mine, you should get your hands on one too.

And don’t forget to spread the word! The more we have there, the better! Rewteet this post, write your own tweets, put a post on Facebook or LinkedIn, blog about it, tell your colleagues; whatever works.

TFS11 and Source Control Improvements

2011-09-19T08:58:00.001+10:00

Now that build is over and we have a Visual Studio 11 we can finally play with I’ve had a brief look at how local workspaces work.

For those who aren’t aware, local workspaces finally removes the number 1, most annoying “feature” in TFS and that is the server-side source control model.

This is the approach where the server keeps track of what it thinks you have on your local development machine and where all checkin/checkout operations require communication with the server making offline work very difficult, and where you can’t make local changes to checked out files because the server wouldn’t be aware of them so all files under source control have the read only bit set. It’s a major pain.

Now there are valid reasons for this approach related to managing VERY large source repositories (think multi-GB of source) and it’s still possible to use server-managed work spaces if desired, but for the 99% of us that just don’t deal with that sort of volume this is a feature we just don’t need. TFS 11 sees the introduction of a subversion style approach to source control with the introduction of local workspaces. Before you get too excited, remember that a local workspace is not a DVCS and TFS doesn’t feature one yet. That said, Brian Harry in a recent post about source control improvements in TFS11 said the following (emphasis mine):

I’m certain that about this time, I bunch of people are asking “but, did you implement DVCS”. The answer is no, not yet. You still can’t checkin while you are offline. And you can’t do history or branch merges, etc. Certain operations do still require you to be online. You won’t get big long hangs – but rather nice error messages that tell you you need to be online. DVCS is definitely in our future and this is a step in that direction but there’s another step yet to take.

There’s also a number of suggestions about source control on the Visual Studio User Voice site that you may want to vote on so that the team makes this a priority, for example Allow the version control system to be pluggable, or you can create one specifically for a TFS DVCS feature.

Anyway, let’s have a look at a few things in the new developer preview.

What’s on our disk after doing a Get Latest?

Firstly, we see we now have a hidden folder in our workspace root

The folder itself contains a bunch of child folders, which are oddly reminiscent of sourcesafe. Thankfully it’s not!

These folders course contain GUID based file names:

And each of those files are simply GZipped copies of your individual source files. Opening them with 7Zip reveals the source files just as you would expect. Obviously you should leave all this alone and not touch it but it’s interesting nonetheless (or at least it is for me!)

Local Source Control Operations

So leaving that aside, what happens when we make file system changes outside of Visual Studio?

To find out I did a simple copy/paste of a few files and renamed a view in an MVC3 project. This is what pending changes shows (the other changes are from the VS11 project upgrade)

So the changes are detected but are currently marked as ignored for now. I get why the copied files are excluded, because they aren’t part of the solution, but I wasn’t sure why the rename was ignored until I realised it had happened because the files I’d chosen were from an MVC3 project and I hadn’t updated VS11 to support MVC3 apps as yet. This mean Visual Studio hadn’t actually loaded the project so wasn’t actively tracking the file that was renamed.

If I click the “Detected changes (5)” link, we see this:

You’ll note that the rename detection isn’t happening in the developer preview though I expect a way to mark add/delete pairs as renames will be provided before RTM. We also have a “promote” button to turn the excluded changes into included ones. Pretty simple. You can also right click files to ignore them (such as upgrade reports, backup folders, etc) so that they don’t constantly sit in the “excluded files” list.

Once we include the files we want, we see this:

Nice. Now, when we’re offline we can’t check in with a local workspace. We have to be connected. When we are, we can click the Check In button and we’ll get a notification message with a link to the Changeset we just added

Local Exclusions

In git, mercurial and other source control systems there are usually configuration files to control the files that source control will ignore (i.e .gitignore and .hgignore) and they are located in the same folder as the source itself so that they can be checked in and shared across all team members.

In TFS there is only one global exclusion file, and it contains all your local exclusions. It lives in C:\Users\Me\AppData\Local\Microsoft\Team Foundation\4.0\Configuration\VersionControl\LocalItemExclusions.config and looks something like this:

    <UserExclusions>
      <Exclusion>c:\temp\tfspreview\scrum project\Trunk\DemoAppSolution\UpgradeLog.XML</Exclusion>
      <Exclusion>c:\temp\tfspreview\scrum project\Trunk\DemoAppSolution\_UpgradeReport_Files</Exclusion>
      <Exclusion>c:\temp\tfspreview\scrum project\Trunk\DemoAppSolution\Backup</Exclusion>
    </UserExclusions>

I’d prefer a local exclusion file (e.g. a .$tfsignore) to live at the solution or workspace root and I’d also prefer it to be glob or regex syntax instead of and XML document, but at least we have something. It’s a start.

Finally, if you want to play with local workspaces you’ll need access to a TFS11 server. The hosted TFS preview service works well for this and if you try doing source control operations over a 3g connection you really feel the difference between local operations and server calls. Alternatively you can download the TFS11 developer preview from MSDN subscriber downloads and install your own TFS server to have a play with.

All up, this is a well overdue improvement in source control and should alleviate some of the pain we all feel when dealing with TFS.

Learning from a FAIL

2011-09-07T14:32:00.001+10:00

Last year at TechEd Australia I delivered a session on Unit Testing that was rated top 10 overall. This year I delivered a group session that has ended up in the bottom 20. Ouch!

So what went wrong? Let me run through a few things and explain.

For those who weren’t there, the session was a group session presented by myself and 3 others and what we wanted to show was how you can use the full Microsoft stack do deliver on the “three screens and a cloud” promise, how the ALM tooling that Microsoft provides (i.e. Visual Studio and TFS) helps with that, and some of the things to watch out for when doing this kind of development. Our vehicle for this was going to be a multiplayer game that runs on both Windows Phone 7 devices and Windows desktops. We also wanted to show how you could extend the experience beyond the game itself and use a single page web application to extend the gaming experience, so we threw that into the mix as well. That’s a lot for an audience to process in a short space of time. Probably too much as it turns out.

Adding to this, re-reading our session abstract I can see how it is easily misinterpreted. It can be read as if we were going to actually build the application on stage. We never even considered that as an option because we though for sure that the audience would be lost, but it appears a number of people thought we would try anyway. I appreciate that you think we can condense 170 hours of development effort into a a 1 cohesive presentation, but we’re not superhuman! :-) This is a failure to manage expectations on my part. If you turn up expecting to see pure, unadulterated, glowing awesomeness on stage and then we present something that makes them seem merely human then you’re going to be disappointed no matter what. Not meeting expectations is a common cause of discontent and I missed the mark here.

Now when we started our session planning we had nothing; no application and only the vaguest of idea on what it might be that we’re going to build, yet we needed something to show so we could have the bones of our session. This meant we needed to build the whole thing in our spare time and this is where the main problem arose – for various reasons the team only finished the application right before TechEd. Further, because of the last minute finish of the application, the remoteness of each of the presenters, and the presenter’s individual TechEd sessions on top of this one, we never managed to get a proper dry run through the presentation with all of us there. We knew the basic idea of what we needed to talk about but we never managed a full practice first.

This in particular was bad! When I’m doing a solo presentation I usually do at least 3 or 4 dry runs first just to make sure the timing is right, that the flow works and that I hit all the points as I want, etc. Preparation is key! I know this, yet did we do it for this particular session? Not really, no. And the results, sadly, showed this.

Because of the lack of preparation, we also had a few “off script” moments that really, really didn’t help. Compounding this is that as presenters we all know each other and are quite ready to joke around and have fun while still getting stuff done. This unfortunately doesn’t translate on stage. Humour in a session is great on the proviso it doesn’t detract from the message, that it keeps audience interest up and reinforces the learning for them. You’ve also got to ensure it’s delivered well and in-jokes or overdoing it certainly doesn’t count in any of these cases. Again, we let the audience down a little by doing this.

Lessons Learned

So, what do I learn? How do I improve for next time?

Content may be king but don’t overload the audience or be too shallow and too broad. We would have been better scaling back on what we did, limiting our content to only a few areas and going deeper in those areas instead of skimming.

Preparation is paramount. Our lack of preparation hurt. Not the preparation in the building of the game (that was fine) but lack of preparation in the delivery of the session. No matter how good (or bad) the software was, if the delivery was good we would have been fine and people would have enjoyed it more. The lack of preparation also contributed to overload of humour on stage.

Set realistic expectations. There’s a trick when writing session abstracts. If you make your session sound too boring you probably won’t get asked to speak, but if you over-hype it then people get their expectations raised too far and you set yourself up to disappoint. More care and attention to the wording of the session abstract would have helped a great deal in this case. It’s much better to under-commit and over-deliver than to do the opposite.

Working in a group is hard. The larger the group, the harder it gets. If I do another group session in the future, the way we work and the amount of time we’ll commit to up front will be clear from the outset. Coordinating 4 speakers when they each had their own individual sessions and limited availability was asking too much from everyone, so when something had to give it was, unsurprisingly, the group session that suffered.

Evaluation Comments

To round out this lengthy post, let’s have a look at some of the comments from the evaluations, both the positive and the negative. I’ll provide my own feedback in italics:

Although I gained a number of tips regarding potential issues there was little here that I can action directly when I get back to work on Monday. The speakers were all fun and had an easy rapport which made this an enjoyable session
Cut the attempts at comedy and get on with presenting what would have been worth seeing at a more even pace. If you hadn't have jerked around with your piss weak in jokes at the start you could have maybe finished up properly. This doesn't apply to Steve. He looked embarrassed to be with you other gooses.
- Whoa! OK, ignoring the bile, your point is taken.
Funny presentation, sometimes a bit over the top, but great stuff nonetheless
- Point taken on the over the top. It shouldn’t have happened. Sorry.
good fun talk, relaxed
Good stuff Ricahrd!!
great presentation - thanks!
- Not our best effort but also not a complete waste of time. Good to know.
I think the material was good but the comedy act they tried to tack on was just distracting and made their presentation look amateurish which is not what I expect for this type of event.
- Agreed. Comedy should have been used sparingly. Mea culpa.
I was looking forward to more on the fly coding, rather than flipping past a pre built project. It would be better for my understanding if the demo was for a simpler project, but setup and built in front of us.
- Expectation management. We probably should have been clearer in the session description about this. Lesson learnt.
Its teched not the comedy festival ;)
- I assume the smiley meant they enjoyed it. Still, backs up the point that we overdid things.
Less talks and more information and code demo was desired
Loved the idea of the talk but the reality wasn't what I was expecting. I was expecting (yes my expectations were probably too high) a simple MMO built from scratch during the presentation, demonstrating the key technologies for each platform. In reality the app had already been built but even then too much time was spent monkeying around instead of showing source code or talking about lessons learnt. Once again like most presentations at teched it would have been great to have a link at the end of the talk to any downloads/links etc. Talk had potential but didn't deliver.
- That last sentence nicely sums up my feelings as well
OK demo, but a bit too simple for business app.
- I thought a title including “MMO” would indicate it wasn’t a business app. Expectation management again.
Session should have had more code examples going through the actual development process.
The 4 speakers probably know the technology, but the whole session came across as a jumbled mess of in-jokes and non-seriousness. Not sure how anyone can manage to "learn" anything from these guys. Please plan the session better or if you really didn't have anything to say, just cancel it.
- Preparation failure on our part. I’m sorry.
The humor and relavence of this session made it very worth while.
- Humour works sometimes, but it didn’t work for everyone.
The session was informative but I think that there the naming of it should have been better as the current title made the room uncomfortably crowded. The presenters were knowledgable in there fields but to me Steve Nagy was the best presenter, properly explaining the process he took in the development of that project. Though I don't mind some joking it really did distract too much from the amount of material that they needed to cover.
the speakers did not realise the audience invested time to see this demo. They enjoyed each other company, but wasted my time.
- Apologies for that. It definitely wasn’t the intention.
There was a little bit too much shenanigans on stage, and too many in jokes, so I think a lot in the audience lost interest. I think people were expecting to see more actual code and implementation (as the session title implied).
This was a very ambitious session and unfortunately, the presenters did not quite pull it off. There was a lot of really cool stuff that these guts were trying to present - but the presentation was low on details, and the attempts at comedy took away from technology being presented
Too busy trying to get a laugh from the crowd, that time could've been spent explaining some of the pitfalls they faced.
too much focus on the "gaming concepts" (XNA/Latency&Prediction), but overall very good session.
- A dry run would have helped balance a lot of the issues raised in the 3 comments above.
Too much time was spent playing about on Stage and not enough on the content. A little bit is good but they went way too far. Points focused on seemed to be very specific to the problems they found with an MMO example, not necessarially translating to what someone else would experience building an app with a cloud backend for the three screen types. The third presenter was more straight up and he actually pulled the about scores up a bit. If I was rating him individually he would get far higher scores for the above, but I would have liked some deeper content, particularly from a 300 session. The one thing that would save this is if we could get a look at the code to actually see how much crossover there is between each of the clients in detail and pull it apart ourselves a bit.
- I’m tossing up wether to put the code up on github to look at, but some of it was very rushed and not our best work. Is that still useful? Blog posts that go into detail may be better.
Very good and informative session. Also the speakers' lightheart approach makes this sessions very interesting. Bravo
Weirdos! Made the session fun
- Erm, thanks for that summary… I think :-)

And there you have it. A very public retrospective from my part on what went wrong, what could have been done better and the lessons to learn.

Publicly talk about your failings is hard, yet there’s nothing that teaches you more than a big, public failure. This is my attempt to do some tough learning in an open way so that hopefully you learn something from it as well.

Finally, if you attended the session at and you thought it sucked, then I apologise and hope that you enjoyed the rest of the conference.

Using Parallel Task Library to Unit Test Threading Issues

2011-09-02T12:04:00.001+10:00

I was doing some work recently on a demo application where data was being pulled in from multiple locations and being added to a collection that was also being iterated over in the same method. Because this data was arriving on multiple threads (i.e. async network call backs for example) I’d occasionally see the usual “collection was modified” error messages indicating that another thread had altered the collection while the first was iterating over it. Obvious threading bug, #FacePlam applied.

While it can be complex at times to find these kinds of errors, in this case it was fairly easy to diagnose and fix, so following good bug fix practices I took the standard approach of writing a test to prove the bug exists, fixing the code and then running the test again to prove it’s fixed.

Now, it should be noted that testing threading issues in a deterministic way is nigh on impossible, and there is no guarantee that a unit test for threading issues will genuinely prove the code bug free, however the approach taken here was good enough to throw the threading exception each and every time I ran the test and also the throw the exception on the build server.

Here’s the code:

[TestMethod]
public void ThreadingFun()
{
    InitializeControllerAndGroup();

    Task[] tasks = new Task[10]
                            {
                                Task.Factory.StartNew(() => MakeMove(1)),
                                Task.Factory.StartNew(() => MakeMove(2)),
                                Task.Factory.StartNew(() => MakeMove(1)),
                                Task.Factory.StartNew(() => MakeMove(2)),
                                Task.Factory.StartNew(() => MakeMove(1)),
                                Task.Factory.StartNew(() => MakeMove(2)),
                                Task.Factory.StartNew(() => MakeMove(1)),
                                Task.Factory.StartNew(() => MakeMove(2)),
                                Task.Factory.StartNew(() => MakeMove(1)),
                                Task.Factory.StartNew(() => MakeMove(2)),
                            };
    Task.WaitAll(tasks);
}

Ignore the first line, that’s just where the collection is being initialised. Also ignore the fact that there’s no Assert statements in this code. The test passes if we have no threading exceptions thrown and fails if we have one.

The important thing here is to see how easy it is to fire off a lot of threads in a single, easy to read unit test without all the usual threading plumbing code that would litter something like this.

The way it works is that we define a set of tasks via the Task Parallel Library (part of .NET 4.0) each of which calls the code where we have our threading problem. When Task.Factory.StartNew() is called the Task Parallel Library (TPL) immediately creates a new thread and calls the method returning control to our code along with a Task object so would can check the state of the task or cancel it if so desired. In this case we don’t care and immediately start another thread as soon as possible.

We then use the Task.WaitAll statement to wait until all the Tasks we defined are completed so that the test doesn’t complete prematurely. Too easy.

Note that we could also just as easily have used Parallel.Invoke for this. The same test using Parallel Invoke would be something like this:

[TestMethod]
public void ParallelInvoke()
{
    InitializeControllerAndGroup();

    Parallel.Invoke(
        () => MakeMove(1),
        () => MakeMove(2),
        () => MakeMove(1),
        () => MakeMove(2),
        () => MakeMove(1),
        () => MakeMove(2),
        () => MakeMove(1),
        () => MakeMove(2),
        () => MakeMove(1),
        () => MakeMove(2)
    );
}

I personally prefer the first approach because I like the more explicit control over the thread creation, though it’s obviously noisier than the Parallel.Invoke version. Note that with Parallel.Invoke you hand over control to the TPL and it figures out how many threads it will use to run the actions you define based on the number of cores available on the machine.

Regardless of the method you choose you can take advantage of the TPL to help you unit test your multithreaded code and make your application more resilient.

How To Run Multiple WP7 Emulators

2011-08-31T16:22:00.003+10:00

The Windows Phone 7 Tools, including the latest Mango update, provide no supported way for running two emulators at the same time. This can be a problem when trying to see how a multiuser application works across multiple devices. Fortunately there’s a way to workaround this limitation using some unsupported edits to your WP7 emulator settings.
NOTE: This is not a supported change and if something breaks on your machine, well… you’ve been warned :-)

Step 1: Open explorer in Administrator mode and go to C:\ProgramData\Microsoft\Phone Tools\CoreCon\10.0\addons

Step 2: Copy “ImageConfig.en-US.xsl” and name it “ImageConfig.en-US 2.xsl”

Step 3: Open this new file in your text editor of choice and locate the DEVICE element and change the device name to something of your choice and the device GUID to a new GUID as shown. Use the Online GUID Generator to make generating new GUIDs easy.

Step 4: Given the WP7 is a virtual machine, we also need to supply a new Virtual Machine ID, so locate the VMID section and provide a new GUID in there as well. Again the Online GUID Generator can be used for this purpose.

Ensure that the GUID you insert is in the same format (i.e. with the braces)

Step 5: Save the file and start the Application Deployment Tool. You should now see your new emulator available to deploy your applications to:

If you close and restart Visual Studio 2010 you should also seen the second phone emulator available as a deployment target:

Note that of you run a phone application in debug mode there seems to be no way to launch a second instance on the other emulator whilst the phone is running. It’s not a major problem though since you can simply take the debug .xap file and deploy it to the second emulator using the deployment tool.

I hope this helps you out. Enjoy!

Getting Out of Sync With IIS and Riding A Comet

2011-08-19T11:39:00.002+10:00

It’s taken a little while but my slide deck from DDD Sydney, 2011 is now up on the web.
Unfortunately I don’t have the code or load test details embedded in the presentation but even so this should still have a number of useful things for you to look at, especially the resources section at the end
Oh, as an experiment, I’ve put both a Slideshare player and a Powerpoint Web App player in this post. I’d like to know which one you think is better (send me a tweet to @rbanks54 or leave a comment)

DDD Sydney 2011 - Getting out of Sync with IIS and Riding a Comet

View more presentations from Richard Banks.

Outsourcing, Unit Testing and Costs

2011-08-12T15:49:00.001+10:00

Let’s say you work in an internal IT department, largely doing maintenance work on software solutions. Solutions that are by and large built by external vendors through an outsourcing arrangement and then brought in house once they’ve gone live and the initial warranty period has elapsed.

Let’s say every time you look at one of these solutions that you now have to maintain you find the grand sum of zero unit tests. Without exception. Every single application has nary a unit test to be seen. Not even a hint that one might have existed and been removed at a later date.

“Why?!” you cry to yourself. In frustration you cry “Why!!?” to management as well. Their answer: The vendors tell us “it will cost more and take longer to do unit testing” and of course, they reason with you, if that’s the case then why would we pay for it? You know this is a bad argument and the logic is built on sand, so what’s your comeback? How do you get it across to management that a vendor that ignores unit testing is a bad vendor and is actually more expensive overall?

So my initial response to their claims would be along the lines of “So do I assume they’re not actually testing the software they write for us then.” and then explain how manual testing takes (much) longer than developing automated tests, assuming of course that the code being written is in any way testable. If they develop poorly and have a lot of tight coupling between concrete classes or make a lot of static calls to HttpContext or develop in SharePoint for instance then the application might not be easily testable, but hey! That’s their problem not ours. The good news is that anyone with a business brain can understand the benefits of automation for tedious repetitive time consuming processes – heck, we worked that out during the industrial revolution.

Let’s try a different angle in case the first, most obvious one doesn’t work. If you consider a lack of automated testing to be merely another form of technical debt then it’s just like poor design and architecture, horribly complex methods, N+1 ORM queries, poor UI’s, high bug counts, etc. It’s something that will cost you. So, if a vendor delivers you software with a high level of technical debt and you’ll be maintaining it, then you’re going to have a lower long term ROI and higher TCO from those vendors versus what you might have from a vendor who keeps their debt levels low. So while the cheap guys may argue that it will cost more and takes longer to write code with unit tests then what they’re really saying is this

“It costs US more and takes US longer to do unit testing because the developers we hire are the cheapest and suckiest we could find. They don’t understand good development practices and we’re not about to teach them because they’ll leave in the next 3 to 6 months. Also manual testers here are cheap-as-chips and lose staff too quickly, so it’s easier for US if we just get the software to ‘it kind of works’ and then give it to you so we can get our money and hope you won’t notice”.

Also, don’t forget that post delivery, all those bugs and problems that snuck through from the vendor will end up becoming your bugs and problems to fix as part of your maintenance work. So the company is either paying for it with internal staff costs (often seen as a hidden/sunk cost) or, if the vendor is also charging for maintenance, paying for it once a development project is concluded. Development takes longer, it’s harder to find and fix bugs, it takes longer and longer to test the application manually, etc. These all add up to time, and in software development time is money!

With that, good luck convincing management to change their vendors, and if you’ve got a better reason to present yours case I’d love to hear it.

Note: I’m not implying manual testing is bad. In fact I think you should be doing manual testing; but only manual exploratory testing where testers are trying to break your code. It’s rote, repetitive manual testing that is neither cost efficient or effective.

Going to TechEd Australia? Lock in DEV305

2011-08-08T10:30:00.001+10:00

Why? Because that’s the session you want to go to of course!

Here’s the link with all the details: http://australia.msteched.com/topic/details/DEV305

Aaron Powell, Luke Drumm, Steve Nagy and myself are going to show you how to build applications for the cloud using multiple clients (i.e. PC and Windows Phone 7 in this case) and some of the things to watch out for. Don’t worry it won’t be one of those sessions where people try and prove how awesome they are by writing the whole thing on stage. Instead we’ll be showing you the highlights and what you should think about if you want to try something similar.

I’ll also have my recording equipment with me and will be recording a number of podcasts for Talking Shop Down Under with people while I’m up there, so if you want to hear from someone in particular, let me know so I can line up a time with them!

True Community is What YOU Make it

2011-07-05T11:35:00.001+10:00

Roy Osherove’s post on "True Community”™ has been making the rounds on the twitterz in the last 24 hours (or as some people have called it “Yet Another Leaving .NET Post”). I feel like I should respond with some thoughts.

First up, let me say I applaud Roy for making his views clear and talking about the differences in the communities and the speed at which the Ruby/Rails community is driving forward. I thinks it great that someone showed enough courage to switch from one technology to another and begin the learning process all over again. What I have a problem with is the deriding of the technology/community you leave. It’s a pretty simple reason too.

The Ruby/Rails community and the .NET community are different communities! There’s no such thing as “True Community”, just community. Calling your community anything else is simply hyperbole, elitism and idealism.

Of course the two communities won’t be the same! They’re made up of different people. Neither will one community be inherently better than another. They are just made up of different people. An apple is not inherently better than an orange or a banana, just because it’s a different fruit. And just because you’ve decided that you like your new community because it’s more akin to your personal tastes, doesn’t mean that those in the other community are ignoramuses, fools, ill-treated and misguided or troglodytes. These sort of attitudes won’t and don’t help anyone.

We’re all developers and we all want to make the best software we can using whatever our chosen technology is. If you don’t like the way your technology or community is progressing or you like the look of other groups more and you leave, that’s fine. Go for it. Be awesome no matter where you go. However if you do leave, don’t then berate those who stay or point out only the negatives as you see them. Constructive criticism is welcome. Criticism that exists just to validate your decision to move is not.

The Ruby/Rails community is still quite small and young and thus is able to change rapidly and innovate quickly. It won’t last forever, it never does, but there’s a lot to like about a community like that, and a lot that everyone can learn from it. I get that. Truly I do. I wish there was more of that going on in the .NET space. Look at the Java and .NET communities on the other hand. They’re much larger and more prone to innovation impedance, making it harder to change things and for .NET in particular when management places more focus on what Microsoft produces to the exclusion of better solutions there can be some real problems.

On the flip side, while Roy makes some strong points about Microsoft not valuing the community, I think they only apply to certain parts of the business. It’s not like that everywhere, and it’s changing. I was on an open source panel on the weekend at the DDD Sydney conference and stated that we’re seeing a gradual change of Microsoft’s attitude towards their open source developers and the developer community in general. The move from closed source to grudging acceptance of open source to a willing approval and active contribution to open source in the community at large has been a slow transition, but it is happening. Why? Because of the very community that Roy complains about is driving change! Groups like Alt.NET that are looking for ways to push things forward regardless of what Redmond says do have an influence. We see the change because of outspoken and community focused people like Roy himself, and others like Ayende Rahien, Sebastian Lambla, Jeremy Miller, the Herding Code guys, the Microsoft MVC team (who have strong community roots) and many, many more.

People that realise that community is what you make it!

So, you don’t like something in a community you’re in? Then what are you doing to improve it. If the answer is “nothing”, then either stop complaining or get off your butt and get active. It’s pretty simple really. Change your community or change your community.

On a side note, the keen eyed amongst you will notice that Roy’s post didn’t mention the JavaScript community? Why? There’s just as much innovation and excitement happening in that space, if not more. What makes them different? Why don’t we see “I’m leaving .NET for JavaScript” posts? Is it because their community is inclusive by nature and the Rails community is elitist? Is it because the technology is server side agnostic? Is it something else? You know what. Who cares! It’s just another community. One from which everyone can learn.

Nothing says you need to be exclusive. You like .NET, Visual Studio & IntelliSense? Wonderful. Go contribute to your local .NET community. You like Ruby and the Rails framework and enjoy the innovation in that space? Fantastic. Go contribute to your local Rails community. You like Java and think there’s still a lot of improving that can be done there? Brilliant. Go contribute to your local Java community. You like JavaScript and think modern browsers have the power you finally need to make some kick ass software? Excellent. Go contribute to your local JavaScript community.

You get the point. The community is made of you so go influence your community.

Fin.

My Geek Origin Story, what’s yours?

2011-07-04T21:13:00.001+10:00

Yay! It’s Meme time, people. This one started by @delic8genius (Michael Kordahi) who wants to learn your Geek Origin Story and see how we all got in touch with our inner geek. So here’s mine…

For me I remember it all starting with the Atari 2600 and a little game called Asteroids, though looking back at photos from my earlier years I can see that the Atari was merely the trigger that brought the latent geek in me to the surface. I mean seriously, look at this photo of me as a little tacker and just ask yourself if that’s not a geek waiting to happen! And no, that’s not a laptop backpack I’m wearing, though it could be! :-)

I spent days and weeks blowing up asteroids in space and leaping through jungles, swinging on vines and jumping over pits (Pitfall anyone?!), but that all faded to backstory when I went to a selective school and my parents decided it was good for my education if they splashed out on a Commodore 64. The day that thing came home, my fate was sealed. As a kid in primary school I remember the unboxing, plugging it into the TV along with the tape drive and an external floppy drive, turning it on and then seeing the blue screen, the blinking cursor and the READY prompt. What now?! We could LOAD something from tape or disk, or we could crack out the programming books that it came with and explore the possibilities! The games were great, but being able to type things into that C64 and watch them run was a revelation! Not only could I play games, and oh! how I played games, but I could write them as well! I remember writing my own text based adventure games (they were crap of course) and building programs that would show animated running man sprites moving across the screen based on how the joystick was pushed. It was a marvel, pure and simple. Being able to make the computer do what I wanted based on my decisions and actions and see the results on screen. Mwahahaha! The power! The unlimited, unfettered POWER!!! *Cough* *Ahem* Yes, what was I saying? I think I got carried away with myself there…

So I’m sure my parents wished I would go play sport with the other kids on the street more often than I did, but I knew I’d never be great at that. Computers however? Different story. I controlled the universe there. They made sense to me. I could figure out how it all fit together. I could PEEK and POKE with the best of them. I got so much joy, fun, fulfilment and square eyes from playing games and writing software that I knew what I wanted to do for the rest of my life. You see, I’m a gamer, through and through. I love playing games and programming is just another form of game. A different form of accomplishment, but still the same sensation that you get from finishing a level or beating a boss fight. Tell me you haven’t got some code working at times and fist pumped, or put your arms in the air in a victory pose! I’m sure this is how half of the world’s programmers started their coding careers – wishing they could spend all their time playing and writing games as cool and puzzling as Boulder Dash or Impossible Mission or Paradroid. I’m no different.

So there you have it. My geek origin story, what’s yours?

Agile Australia: A Retrospective

2011-06-20T16:31:00.002+10:00

Last week I was a panellist at the Agile Australia conference, talking about hiring people for agile teams, and whilst that was fun the conference overall left me feeling cold, frustrated and disappointed. Anyone who saw my tweet stream during the conference would have probably felt some of that and now that I’ve calmed down a little and thought about things some more, I think it’s time to get to the heart of what really annoyed me and offer some suggestions as to what to do next time. Consider this constructive criticism.

Firstly, it felt like conference sponsors were given slots based on the amount of sponsorship they paid. The title sponsor had the largest number of slots and each of the gold sponsors also appeared to have the option to take slots. The problem I have with this is that a staff member from the title sponsor was also part of the advisory panel, as were staff from their major customers. Conflict of interest anyone? What we saw in the conference were “case study” sessions presented by large corporates who just happened to be customers of the sponsor or sessions from colleagues of other advisory board members. It meant that the event became largely a marketing exercise targeting other large corporates wrapped in conference clothing with very little to offer for anyone working in small organisations or who is already practicing agile and looking for ways to improve through learning from others. The worst session was one where the presenter decided to slowly read a carefully prepared, PR laden, speech. No slides, no audience engagement, just fluff. That sort of thing is simply unforgivable, and even now still gets by blood boiling!

Given one of the key principles of being agile is having the courage to be open and visible with the process I can safely say that this was not an approach followed by the conference. What I would like to see? Community voting on topics, with all submitted sessions available and open for the public/attendees to vote on. If sponsors are getting a number of slots then indicate how many by blanking out their sessions on the schedule, that way we can also see just how much non-sponsor content we may get.

Next on my gripe list. Most sessions were targeted at beginners with content rarely reaching the ‘200-level’ let along going beyond that into more advanced and deeper topics. I’m fine with a number of sessions being beginners based, but to have most of the conference aimed at that level? Urgh! At least mark the sessions with some sort of required knowledge levelling system. It’s important to have sessions marked as “best for beginners”, but please, not the whole conference!

Moving on from that, there was also very little opportunity for ad-hoc discussion with other attendees. The “Individuals and Interactions” aspect of agile should apply to conferences too. Now there were a number of panel sessions, but a panel is nowhere near as interactive as an open space, and asking questions in a room of 200 is much harder for most people than in a group of 20-30. The only open space time in the conference was a 45 minute session at the back end of day 2. This, for me, was far and away the best part of the conference as it meant I could finally sit down and discuss problems and issues with other people and bounce some ideas around, but because of time limitations we really only had 15 minutes per topic. This is just enough time to really get started in on a topic but not enough to get far beyond the shallows. Frustrating! I’d like to see an entire day put aside for open space topics. Make day 1 a “fixed content” day and day 2 an open spaces and workshop day so that we can really dig into things and learn from each other.

Finally, let’s talk about the keynotes. 2 of the 4 were keynotes were good, though the content was unfortunately recycled. The other 2 sessions were terrible. One featured 40 minutes of name dropping, self promotion, marketing and trite stories without any real content at all, and the other was a cliché-ridden, pandering, hippy themed “lets all love each other because we’re all geniuses!” farce. Why a 2 day conference needs 3 keynotes and 2 lock notes is beyond me. I want less of that nonsense and more content next time, just not more toddlers level content!

And if you’re wondering if I would recommend you attend next years Agile Australia conference, and things don’t improve dramatically, then here’s my answer: If you work in a large corporate, are new to agile and you’re still trying to figure out how to make it work for you then yes, but take your marketing proof earmuffs with you. If that’s not you, then stay well away. It’s a complete and utter waste of time.

DDD Sydney, 2011 – Saturday, July 2nd

2011-06-06T20:59:00.001+10:00

Are you an Aussie dev? Based in Sydney or somewhere within driving/flying distance?

Well, why don’t you get yourself along to DDD Sydney this year? Not only will you have a chance to hear me wax lyrical about Comet with IIS and how async coding can help improve performance, but you’ll also get to partake of a slew, nay a plethora!, of topics from other great speakers.

Apart from my talk, I’ll also be a panellist for the Open Source panel, and I’m facilitating the Web Panel later in the day, so at least you now know which sessions to avoid, right? :-)

Jokes aside, last years DDD Sydney was a lot of fun and this year will be even bigger – the agenda and registration are now available. Go check out the details, book yourself a ticket, and I’ll see you there!

Anaesthetic for your #region-itis

2011-06-06T10:57:00.001+10:00

If your code (or the rest of your team) suffers from a bad case of #region-itis then help is at hand.

There’s a lovely little Visual Studio extension over at http://teamsearchapp.com/region-tool that will automatically expand #regions, and also make those #region lines much smaller and harder to read than your normal code. No more pressing shortcuts to expand all those blocks, less visual clutter and optionally, the ability to prevent collapsing of #regions. What’s not to like?

Borrowing a few pictures from their site, it takes the #region afflicted code (on the left) and reveals it’s ugly inner truth (on the right):

Ahh! That’s much better.