MEF and the Personal Spike

A week or two ago I attended the Open Space Coding day arranged by Alan Dean, and held at the Conchango offices. The Alt.Net community is very good at getting together and talking about code, software, and how it should all be done, but the focus of this meeting was to get on and write something!

The format was much like an open space conference, the first thing we did was suggest things we’d like to look in to, experiment and play with. There was a morning and afternoon session, in the morning I went to one on static reflection. A very interesting technique of using lambda syntax to analyse code as a traversable tree of expressions. All very good. Unfortunately for me this is the opportunity my Windows 2008 Server VM on my MacBook decided to bomb out on me. And bomb out it did. Blue Screen of death even before windows got a chance to get it’s boot on. How embarrassing, there was me thinking, I could finally be one of the cool kids, with my shiny white MacBook with after market Ram and HD upgrade just so I could run Windows in a VM, and it all fell apart.

From the Static reflection session I took away that it did make me a whole lot more comfortable with the reflection thing. Up until now I had always treated it like a leper of hackery, unjustly so, but this experience made me much more comfortable. It did appear to me that there was space here for a good library to make the traversal of the tree a lot more intuitive. Let me know if you know of any or if I missed something that made it all a lot easier than it looks.

The second session I attended was one on MEF. As we were all new to the format (or at least I thought we were) this got off to a bit of a slow start. We did that thing where go in to a room preped and briefed not to expect anyone to lead and then stare at someone who seems to know more than anyone else until they stand up and start presenting. Andrew Clancy, an Conchango employee, admitted to have played with MEF, and so showed us all very basically what its all about.

Once we had been briefed we paired up and made our own toy examples. I think it was a good thing that Andy’s example was out of date and the version of MEF we all downloaded was completely different. It forced us all to learn a bit better how it all worked. Mike and I quickly came up with a toy example that involved contract killers.

We quickly cut two dlls, that each contained one type of contract killer. MEF made it unbelievably easy to export this implementations of IContractKiller. Just attribute them up and they’re ready for consumption. The contract it self was also implemented in it’s own library and finally we had a console app that would tie it all together and offer up some victims to be killed (in various ways).

MEF allowed us to simply load all the dlls in a directory and in an IoC like way made them available to plug in to IContractKiller shaped holes (properties tagged with corresponding attributes). It also rather neatly allowed us to get all the implementations and put them in an IEnumerable for us to use.

Now here’s what I really learnt at this day. I knew about MEF when it was released and have seen many a blog about people using it (seen, not read). But only when I actually played with it, did it start clicking, how I could leverage this in my work. Where it might be appropriate to alleviate some problem we were having, and also where it wouldn’t be so handy. It’s very easy to get carried away with a new toy. Scott Cowan who also attended the session described this to me as a personal spike.

Take an hour or two, some time boxed period, branch your code or knock up some simple harness, and just play with something you’ve not used before. Something you’re interested in learning. With no goal other than to learn a little more about what it is you’re playing with. As is described in Pragmatic Thinking and Learning by Andy Hunt. Learn by play really does work. It may seem obvious but reading about something really is totally different. Andy explains that it’s because it uses a different part of your brain, and that neglected part, the play part, seems to have a hidden ability. To perculate and strike you in the down time. Let your mind wander a little and it often does go find something interesting and useful!

Woo, my first post written and published in one sitting. I hope it doesn’t show (much).

Agile session Alt.Net London

So to start the conference I chose to take part in a session about agile development and processes. I think mainly because I wanted a refresher on some of the points and to see if I could contribute. It’s nice to see plenty of people there new to Agile as I was at my first open conference. Learning the basics of the process, and making a good start. I was also interested to see how people had developed from their initial attempts at introducing Agile to their shops.

At one point there was a lot of talk about how we estimate, and I was surprised to see that everyone had assumed estimating in hours and half days. Assigning some time to points and then estimating with points. I wonder what happened to estimating by points representing complexity. At uSwitch, when we introduced planning meetings and planning poker, we started with 5 points to a day. This was mainly to get developers used to the idea of estimating in points and as a team. Over time in teams where this method had remained, they have naturally loosened the tie between the points and the number of hours they represent when estimating. They still use the rule to define how much capacity they have in a given iteration, 5*Devs* 10days = capacity.

For me and my teams, we’ve moved this to the next logical stage of entirely decoupling estimation points from time and tying them to the complexity of a task. Has this gone out of fashion and no one told me?

I think I’ll break this off into a separate post on estimating

Crystal and full project breadth

Ian Cooper shared with the group the method or agile flavour he’s using with his current team, it’s called Crystal and sounds interesting. It sounds like the emphasis of crystal is the continuous improvement and customisation of the process to your team and project’s needs. A quick bout of googling tells me that the following has not much directly to do with Crystal. From what I’ve been able to gleam (and it’s not much) Crystal is primarily focused on improving methodology frequently, aiming to minimise it’s weight.

The main point that Ian brought up that caught my attention was the move from the pure priority prioritisation to a more whole system or breadth approach with incremental refinement. Purely working of stories by priorities, apparently leads to systems that have a lot of work and attention spent on apparent high priority sections while those features and functions that the client may deem as a lesser priority are essentially neglected, typically tacked on the end of the project. This can lead to seemingly unfinished projects (my conclusion).

The three thirds approach that Ian described seems to encompass the entire system with increasing levels of ‘focus’. The first phase is the ‘Walking Skeleton’ this is just enough of the entire system to get something going from a technical perspective, this might take up most of the ‘framework’ stuff that one has to do to get a project going. Many people likened this to an iteration 0, which doesn’t deliver much or any business value but is necessary to build something you can demonstrate.

The next phase delivers the ‘First Business Value’ taking the walking skeleton and adding enough to actually add to what the business has, making a contribution.

Here is where my notes get a little woolly and I wish I wrote this post while I was in the room! The final phase adds all the other features, improves on the initial business value, works on feedback from the client on the second phase, and perhaps includes changes to requirements.

From the weakness of those last two paragraphs, I think I’m definitely going to do a little more research, so check back for a bit more bulk in later posts.

This notion of increasing the focus with subsequent iterations really did intrigue me, and I’m definitely going to see how I can apply it to our next project.

altdotnet London September 2008

So, I’ve just got back from the altdotnet conference in London. This is my second altdotnet conference, and it was as good as I remember. You could see people had moved on, and it was nice to see that altdotnet has had its affect on uSwitch.com in a positive way. 5 attendees were currently employed by uSwitch, that’s a great improvement from the 1 from last year.

As always at open spaces events, I do wish I was less passive in my contribution, but every time I did pipe up someone else got to where I was going but probably more clearly than I would have. Maybe by the next conference blogging will have helped improve my confidence and clarity.

I aimed to learn about acceptance testing and how I could move that piece of the agile puzzle forward in my organisation, and luckily Gojko Adzic was in attendance. He literally wrote the book on using Fitnesse for acceptance testing, and clearly had lots to say. I attended (accidentally) two sessions on acceptance testing. Our BDD talk quickly moved on from the standard definition argument to a broader discussion on how ‘Behaviour’ should inform our acceptance tests and involve all stake holders rather than just be a developer concern. I think I’ll separate out my write ups on the different sessions I attended.

Ian started the conference with a quick demo of the Park Bench method of a open space session, and chose the controversial subject someone had brought up in the previous nights session brainstorming exercise. Is altdotnet = faddotnet. The park bench quickly ended up being the same old are we anti msoft, should we be, why are there so few of us, why doesn’t anyone else care, this session was the closest to an alcoholics anonymous I wanted the event to get. (We’re only ever two step aways from that in an open space conference).

I really did start wishing we stopped concerning ourselves with how we’re perceived. It seems only ever really to be a concern of people who are unsure they want to wear an alt.net badge. To them I say, don’t! But if you’re interested in the things we do, and interested enough to read our blogs, attend our meetings, then you’re welcome. I think the difference between an alt.net’er and a microsoftie, is the just the plain old giving a damn. Enjoyng what we do for a living, with just a little mix of compsci for added goodness, but not so much that we end up being java devs 🙂

It was also good to brush up on some of the basics of Agile and DDD, just to remind myself on what I find so interesting about my job. Thanks guys! Now for me to work on giving some back….