Fear and Loathing

As I'm staring at my blank Team System setup waiting for the system to work again, I thought I would share a few Scrum for Team System tips with you. SFTS has done a pretty good job for us (much better than the stock templates Team System comes with) but it does have it's issues and problems (like the fact that PBIs are expressed in days and SBIs are expressed in hours, totally messes up with the Scrum concept and makes PMs try to calculate "hours per point"). I'm really digging Mingle though and will be blogging more on that as we're piloting it for a project right now and I'm considering setting up a public one for all of my projects (it's just way simpler than Rally, VersionOne or any other Agile story management tool on the planet, hands down). 

• When a sprint ends, all outstanding PBIs should be moved to the next sprint and the sprint marked as done.
• The amount of work done in the sprint (SBIs completed) gives you the capacity (velocity) for the team for the next sprint.
• Only allocate one sprints-worth of PBIs to a sprint when planning and try to estimate better based on previous sprint data.
• When the customer decides the product is good enough for shipping have a release sprint where the goal is to "mop up" bugs and polish the product ready for shipping. This would include new PBIs like:
  • Fix outstanding bugs
  • Create documentation
  • Package/create MSIs
• Never attach new SBIs to previously closed PBIs. If the customer changes his mind about the way something is implemented, it is recorded as a new PBI because the requirement has changed.

Definitions:

PBI: Product Backlog Item, can be functional requirements, non-functional requirements, and issues. Comparable to a User Story, but might be higher level than that (like a Theme, depends on how you do Scrum)

SBI: Sprint Backlog Item, tasks to turn Product Backlog Items into working product functionality and support a Product Backlog requirement for the current Sprint.

Bil was struggling with the question. What would you rather have? No source control or no tests.

Let's go back a bit to Friday morning when Bil came into the office to find himself alone (it was 5:30AM and what ungodly soul would be at work at that time?) and unable to connect to the Team Foundation Server. It seems the drive that contained the database files filled up. Oh it gets better. No only did the data drive fill up (and BTW, the data files AND log files were on the same drive, not the way I would have set things up) but (drumroll please...) no backups. Somewhere along the way the SQLAGENT was disabled and frankly, when it's disabled nothing really works, including backups. As the data drive filled up, the transaction logs filled up and eventually became corrupted, unreadable, and unrecoverable.

The short of it that I'm left with a Team Foundation Server and it's databases with no log files. Not the end of the world (at least I don't think so) and there are techniques for re-mounting a file without the associated .ldf file. Grant you, if there were any transactions in play they would be lost, but this was the morning and the drive filled up sometime throughout the night (probably during a build).

At this point we've tried a variety of things to restore the databases and strangely enough we got them all back online. All but one. TfsVersionControl is the table that (yup) holds all the source code for Team System projects. A single table that just refuses to restore. The single remount trick (which worked for all of the other databases) doesn't work for this one (of course) so we're turning to PSS to help us fix this. There are a couple of "hacks" where you rebuild the database and swap out the data, but again for some reason it won't work. The best and closest we got was getting TfsVersionControl back online, but checking a solution out (any solution) ends with an error about "downloadUrl" being null, and the checkout stops.

So tune in again tommorow as the geek suffers. We'll see how things go, but as a last ditch effort we do have the latest code on the build server (a separate box) which has the latest checkout so we technically *could* rebuild the projects, we would just lose source control history which in the grand scheme of things, isn't the worst thing in the world.

A system with no source control, or a system with no tests?

Personally I would rather have a system with no tests. At least with tests I can write them. With no source control, well, welcome to my Monday morning.

It's going to be a long week.

The Alberta Architect Forum is an opportunity to learn from your peers as well as experts on practices and directions in the real-world. An exclusive invitation only event, the Forum allows top architects in Alberta to interact with presenters and discuss architectural issues as well as future directions and technologies from Microsoft.

I'll be speaking at Monday's event here in Calgary on Software Factories (and specifically the Web Service Software Factory). Here's the day's agenda:

8:00 am - 8:30 am: Breakfast and Registration
8:30 am - 8:45 am: Welcome by Dave Remmer
8:45 am - 9:15 am: Architectural Agility as Business Value, Dave Remmer
9:15 am - 10:00 am: Architecting for Testability, Mike Mason
10:00 am - 10:15 am: Break
10:15 am - 11:30 am: Introducing Web Services Factories, Bil Simser
11:30 am - 12:00 pm: Office Business Applications, Dave Remmer
12:00 pm - 1:00 pm: Networking lunch
1:00 pm - 2:15 pm: Creating Flexible Software, James Kovacs
2:15 pm - 2:30 pm: Break
2:30 pm - 3:45 pm: Designing and Building Real World SOA with WCF, Daniel Carbajal
3:45 pm - 4:30 pm: Silverlight and Rich Internet Applications, John Bristowe
4:30 pm - 4:35 pm: Wrap-up and Prize Draw

Should be fun, although I'm only going to be there for my gig as I'm rebuilding a crippled TFS server and our source control is offline at the moment (backup, backup, backup!) but feel free to come out for the days events as they'll be lots to soak in.

The event is taking place in the Wildrose room at the Sheraton Suites in Eau Claire. You can register and check out the details for the event here.

I have a lot of respect for Jim Newkirk but I was reading Roy Osheroves blog entry about the new XUnit.NET framework that has just been released and I'm scratching my head wondering why. While it has been a few years since the original NUnit framework was released, .NET has evolved and continues to do so, Jim (and others) felt it was time to clean the slate. What bothers me are some of the same things mentioned in Roy's blog.

I do agree with changes they've done on some parts. For example, I'm now in the camp that [SetUp] and [TearDown] are evil and need to be abolished. Easy enough. I tell people not to use them and if I really had to I could create a custom FxCop rule or something to prevent check-ins with them. However in XUnit.NET they just don't exist. The problem I have with XUnit.NET is that other things have changed, and quite drastically (after downloading and playing with it for a couple of hours). [ExpectedException] is gone in favor of the more JUnit like Assert.Throws() approach. This is fine, but it means more code changes to tests that already work.

On the positive side, there is extensibility but I have to ask. Why oh why can't we all get along? NUnit is great but I've recently (the last couple of months) shifted over to MbUnit which seems to have a little more life and there are some nice features I'm getting productivity out of. Why couldn't say the 3 cheeses (Andrew, James, and Charlie) get together to say "Let's build a unified framework". On unit testing framework for .NET to rule them all. True, it might drag along the Microsoft approach to backward compatibility, but when we're out there trying to get people to do Agile and write good code with unit tests, I think it's a good thing rather than having to tell them "Oh yeah, and you have to rewrite X% of your already-working-and-nothing-wrong-with-them tests". Sigh.

Roy mentioned a few other things that irk me. No Assert.Fail. Well, the only reason I used it was to call it at the end of a test that had an [ExpectedException] tag so that it would fail if it fell through to there (I know, it would probably fail on the missing exception so it might be moot). Still, dropping this completely isn't cool. The bigger thorn in my side is Assert.Equals being deprecated in favor of Assert.Equal<TypeToAssertAgainst>. That's just plain mean and goes back to rewriting X% of your working tests. That would be like changing some HTML tag just because some cool new syntax is available. I see no redeeming value in doing this based on looking at the code for both. The TheoryAttribute is nice, but I already have that (and more) with MbUnit's [RowTest] and extended attributes.  Frankly, I see XUnit.NET as a framework that a) removes some features which some people use b) forces you to rewrite perfectly working tests and c) adds very little that you can't get elsewhere already.

Like Roy, I'm not about to jump on this bandwagon and I don't suggest you do either. If you're looking to start writing new tests with it, I guess it's okay (other than the things mentioned above) but that's for you to decide. If you're looking to replace NUnit or MbUnit with XUnit.NET forget it. It's not worth it as a lot of your tests might break or worse case, you'll have to actually just replace code via rename because of the syntax. For me it took me about 10 minutes to move 2,200 unit tests from NUnit to MbUnit in a project. I would suspect looking over the list of changes in XUnit.NET that it would be a significant change to move those tests to XUnit.NET. Not worth it in my books and a new unit testing framework today, unless it's really fixing a real problem we have, doesn't make a heck of a lot of sense.

I go back to why can't we all get together and build a unified testing framework for .NET and be done with it. MbUnit (and NUnit for that matter) could have been giving some attention and perhaps the extensibility model could have been applied here. I'm not saying that we need one and only one unit testing framework, but we certainly don't need a dozen. CsUnit seems to have gone by the wayside in favor of NUnit and MbUnit. VSTSUnit (or whatever it's called, if it has a name) only exists because it's there and people don't know any different. I'm all for competition and adding something new to the mix but only if there's value-add and we're not just telling people that the new Red is Blue. Now it's getting silly with all the choices because there's little bang for your buck with some of them (especially XUnit.NET). I personally feel like I'm getting shafted like I do at the video store and my DVD collection. DVD comes out in it's normal form. Pay. DVD comes out in Directors Cut. Pay. DVD comes out in Extended Directors Cut, but this time it contains a special version with extra commentary you can't get anywhere, but they decide to drop some of the additional features that came out in the Directors cut so if you want both features you have to buy both copies (plus the original because it contains some special interview that got discarded along the way). Too many choices, too confusing to end developers to try to choose and frankly, why should they? Slam them all together and call it a day.

Huh? Dopewars? BlackBerry? That's not SharePoint. That's not Agile. Am I reading the right blog? Yup. You are. Really.

It's been awhile since I blogged here as I've been wrapped up in Baby 1.0 and a slight vacation off the grid in British Columbia (with 300 photos to pull off the camera and sift through). However I thought I would post this here as it is development related, just not my normal train of incoherent thoughts and creations.

A couple of months ago I got a new cell phone and decided on the BlackBerry Curve for a variety of reasons. Constant connection, compact, cheaper than the iPhone, etc. It was a toss up between the BlackBerry and an HTC Windows Mobile phone. Of course the Windows Mobile would be nice since I'm a bit of a Microsoft guy, but the BlackBerry won out in features and reliability. Of course, what's the first thing you do when you get a SmartPhone? Why, hunt for games silly rabbit.

There I was combing the BlackBerry archives looking for something good and came across DopeWars by Mark Sohm. I installed it and was immediately taken back to my BBS days when I ranked high in the echelons of the digital drug dealer world. The game was fun and would let me kill the hour ride on the train to work. The game was well done, easy to play, and adhered fairly true to the original although with it's own conversion to the UI constraints imposed by the BlackBerry. Still, it's fun and IMHO a good app.

Anyway, the development bug got to me and I discovered that BlackBerry apps were Java based. Not a horrible language (beats the heck out of C and the PalmOS that I played with years ago) so I set out to create my development environment and try my hand at building BlackBerry apps (still trying to build a CCTray for the BlackBerry). The SDK documentation was pretty good and contained a wealth of examples but for me, I really need a good example to pull all the bits together.

That was a bigger challenge, as anything out there in the open source land was pretty sad (from the Java/BlackBerry perspective). Lots of samples, but nothing that either a) worked or b) was a good example to understand how to glue things together. Most samples were sparse and the ones that were quite involved were so convoluted they looked like a poor mans attempt at converting Visual Basic code to C to Java (or some such silly thing).

Then I thought about DopeWars. Maybe it was another fish in a sea of crap code, but then again maybe not. I hunted down the files but couldn't find the source anywhere. So a little Internet detective work and I tracked down the author, Mark Sohm, who just happened to work for Research In Motion (the makers of the BlackBerry). Someone who works for the company writing a game? Why not. Mark had put the app together in his spare time and after a few emails I nudged him into releasing the source code as an example of writing a Java game for the BlackBerry.

A few weeks later and yet another new SourceForge site is born. You can download the binaries for DopeWars for your BlackBerry Curve (well, any Java enabled BlackBerry with colour capabilities) from here. The source code is up there and available via anonymous SVN access (instructions here). I will be putting together a source code zip file for those that don't have (or don't want to) install a Subversion client. Note that there was already a "DopeWars for BlackBerry" site on SourceForge but it consisted of C++ code that doesn't seem to compile and doesn't have a binary release so I considered it abandoned and just made another one.

I won't be doing too much development on the project (I barely have time for my current projects), but being open source (released under the MIT license) anyone can contribute to it. Feel free to fix bugs or add enhancements. Via SourceForge you can post suggestions in the forums or use the tracker (bugs, suggestions, etc.) or email me if you would like developer access to the project (just include a note about what your plans are for the code). There is one bug that bugs me and that's when you finish the game. You end up finishing when the day turns 31 rather than at the end of the 31st day. Personally I think it should let you finish any transaction on the 31st day then end. Otherwise, it's quite stable code and well separated (for a BlackBerry Java app) in terms of responsibility and separation of concerns.

So give it a look see if you have a BlackBerry, are interested in what a BB app might look like, or just want to poke around. Who knows, you might like it.

We came up with a weird error that I've never seen before today. Here's a customer class and an interface to a strategy class (ICustomerStrategy) with two concrete implementations (GoodCustomer, BadCustomer):

   1:      public class Customer

   2:      {

   3:          private readonly int _creditLimit;

   4:   

   5:          public Customer(int creditLimit)

   6:          {

   7:              _creditLimit = creditLimit;

   8:          }

   9:   

  10:          public int CreditLimit

  11:          {

  12:              get { return _creditLimit; }

  13:          }

  14:      }

  15:   

  16:      public interface ICustomerStrategy

  17:      {

  18:      }

  19:   

  20:      internal class BadCustomer : ICustomerStrategy

  21:      {

  22:      }

  23:   

  24:      internal class GoodCustomer : ICustomerStrategy

  25:      {

  26:      }

In the consumer class we have a method called GetStrategy that returns an ICustomerStrategy object.

This statement using an if-block works fine:

   1:      public class Strategy

   2:      {

   3:          public ICustomerStrategy GetStrategy(Customer customer)

   4:          {

   5:              if (hasGoodCredit(customer))

   6:              {

   7:                  return new GoodCustomer();        

   8:              }

   9:   

  10:              return new BadCustomer();

  11:          }

  12:   

  13:          private static bool hasGoodCredit(Customer customer)

  14:          {

  15:              return customer.CreditLimit > 1000;

  16:          }

  17:      }

However this statement using the conditional operator doesn't:

   1:      public class Strategy

   2:      {

   3:          public ICustomerStrategy GetStrategy(Customer customer)

   4:          {

   5:              return hasGoodCredit(customer) ? new GoodCustomer() : new BadCustomer();

   6:          }

   7:   

   8:          private static bool hasGoodCredit(Customer customer)

   9:          {

  10:              return customer.CreditLimit > 1000;

  11:          }

  12:      }

The only way to make it work (thanks ReSharper for the tip!) is to cast the first object to the interface like so:

   1:          public ICustomerStrategy GetStrategy(Customer customer)

   2:          {

   3:              return hasGoodCredit(customer) ? (ICustomerStrategy) new GoodCustomer() : new BadCustomer();

   4:          }

You can also make it work by using a base abstract class rather than an interface, but I prefer the interface driven approach.

So the question on my noodle is... why?

When I started SharePointKicks a little over a year ago, I thought we were starting a good thing. Gavin Joyce had created a small community around DotNetKicks and we started building up sister sites to it, which included SharePointKicks. The idea was solid. Community driven content, allowing you dear reader the ability to bump up the stories you thought were worthy so they were there at the top, waiting to be read by others who were looking for the good stuff. Lots of signal, less noise.

As with any community, it had to start somewhere. It was me posting various stories from the SharePoint blog-o-sphere and getting the word out. However it's not something anyone should do full time. Do you think Kevin Rose feeds digg with all of it's stories these days? I'm not comparing SPK to digg on the level of popularity but rather concept, since they're both the same, although SharePointKicks is more specialized for the IT crowd.

After a month or two I felt the site had gathered up enough momentum and people would drive. Guess I was wrong. Back in May I posted a note about how the community had fell a little by the wayside and was suffering for it. At that time I thought there was still enough interest to keep the site going, however today it doesn't seem like that's been the case.

So here we are looking into the chasm. The last popular post was submitted over a month ago on the site. There are a few people that post and the items trickle in, but that's it. They trickle. Like a dried up well with little life and less interest. And most of the entries are spam these days, which I've been cleaning out but it's a time-consuming job for which I don't have the time to do.

From the looks of it, the SharePoint community (that would be you guys, myself included) doesn't seem to want to keep this beast alive. Or do you? Like the infamous Andy Kaufman vote on Saturday Night Live in the 80s, I have to ask the question. If there isn't going to be an overwhelming "oh, don't take our SharePoint kicks away!" from a large number of people who are committed to seeing the site grow and flourish, I'm going to shut down the site. We'll redirect the domain name to DotNetKicks, which continues to move along nicely, but ultimately shut the site itself down. It's a shame as I thought the site would make a difference for those wading through SharePoint information out there but I don't see that it is. I know there's plenty of news stories, but I can't keep up the pace of posting them all myself so if the users of a community can't drive a community site like this then I don't see the point in keeping it around.

Let me know what you think via comments on this post or through email if that's your thing.