MEF: Getting Started

One of my side-projects (“Tomato Timer”) has plugins as a central design characteristic. Now, I have never built an application that relies on plugins before – so when it came to thinking about what framework I could use – MEF was an obvious strong candidate.

What is MEF?

MEF stands for “Managed Extensibility Framework”. It’s a framework developed by Microsoft for .NET developers to allow them to easily pull components out from the main compiled assembly, and dynamically “compose” them at run time.

This behaviour is shared amongst most modern IoC Containers and is a very powerful pattern. The ability to easily swap out components not only facilitates plugins, but ease of testability, maintenance and improved design.

Why Did I Choose MEF?

I decided to go with MEF because:

• I have never worked with it before.
• I want to compare it’s usage against IoC containers.
• I like saying “I am doing MEF” on the phone to my non-geeky friends who then get concerned for my welfare and start telling me to “talk to someone”.

Basic MEF Terminology

Here’s a quick run-down of the terms you will see when first getting up and running with MEF:

Imports

“Imports” are basically in inputs to your application from the outside world. This essentially says to MEF: “I want you to find me some code that tells me it can give me X”.

   1: // Find code that can give us a List of Strings.

   2: [Import(typeof(List<string>))]

   3: List<string> ImportedStringList { get; private set; }

Note in the above code all we have really done is decorate a property that we would likely already have in our code.

I personally do not like the fact that we need to specify the type to the attribute, but I guess the MEF team have their reasons. :)

Exports

The exact opposite to Imports, Exports are the outputs of your code. These work in tandem with the Imports to glue things together. When you ask for an Import(typeof(T)], MEF will run off to find code that has a method that returns “T” that is decorated with an Export attribute.

   1: // Declare that we can satisfy the previous Import

   2: // by returning a List<string>

   3: [Export(typeof(List<string>))]

   4: public List<string> GenerateStringList() { /*...*/ }

Catalogue

Or “Catalog” for our friends across the pond :)

The catalogue is essentially the code that is searched for Exports to use for Imports. The two most common are “AssemblyCatalog” (which scans an assembly) and “DirectoryCatalog” (which scans a given directory).

   1: // Get All Exports in the Current Assembly

   2: var asmCat = new AssemblyCatalog(

   3:     Assembly.GetExecutingAssembly());

   4: // Get All Exports from the "Plugins" Directory

   5: // (relative to the application directory)

   6: var dirCat = new DirectoryCatalog("Plugins");

Container

The container (or Composition Container) is basically the holding area for the types that are loaded via MEF. In most applications you may only have one of these - but it is possible to have more than one as well as nest them (useful for defining hierarchies or managing scope).

   1: // Create a new Container based on

   2: // the Current AssemblyCatalog

   3: var asmCat = new AssemblyCatalog(

   4:     Assembly.GetExecutingAssembly());

   5: var container = new 

   6:     CompositionContainer(asmCat);

Composition

The process by which MEF discovers the types available and initialises them is known as “composition”. We ask our Container to “ComposeParts” which will then scan the catalogues we have added to the container for types.

   1: // Ask the Container to begin Composing

   2: // based on the Catalogues available.

   3: container.ComposeParts(this);

Note the reference to “this” in the method call, this is to basically associate our client code with the container (since this is where the imports are specified).

Initial Thoughts

I personally still have a lot to learn with MEF, but I can tell you this:

• I had built a basic MEF application from start to finish in 1 tomato (25 minutes). This was essentially a basic string transformer which also used re-composition to pick up new plugins at runtime without a restart.
• The syntax is relatively clean – you don’t need to do much to get your objects.
• I like the fact you can get the source on CodePlex.
• It’s working pretty damn good and still only in preview (7 at time of writing).
• They have some great people that offer a lot of support on the team both in the discussions and on twitter (e.g. Glenn Block or Nicholas Blumhardt).
• I have completed most of the core plugin code for Tomato Timer that I was working on, MEF made integrating it really easy!

Work Hard. Play Harder.

Freelancing: Your Thoughts Please..

Recently, I have been giving my current employment model some serious thought..

The Problem

Put simply, I feel like I need more out of my working life. I love what I do – but I am not satisfied with several aspects of my career. This is including (but obviously not limited to):

Experience Growth Rate

It’s all 9-5, same old technologies, same development practice etc. I have been learning massive amounts in my own time – but I need to be in an environment where I can truly apply what I have learned.

Client Contact

I love writing software for people. I enjoy talking to them about the problems they have and thinking of how we can work together to solve it in the most efficient way possible. In my current employer, I rarely get the opportunity to really sit down with the people that truly matter.

Management Style

As you may have noticed from my recent blog posts – I am always looking at ways to improve the way I work. My working process is very evolutionary. I think this is important to make sure I get the most out of my time. If I am more in charge of my time, I have more control about how I apply it.

Project Management Experience

I know I need more experience in managing projects at a higher level. I think in order for me to become a better developer I should have more of an understanding and appreciation for project-level constraints and issues (such as budgets, resourcing, third-party management).

The Solution?

Ultimately, I want to develop a company and build my own line of core products. However, this is going to take a fair amount of time since I am obviously going to be bootstrapping it myself. So, I began thinking about other options. Freelancing was obviously the next big thing that came up in my mind. I feel it will directly attack all of the above.

In short, I am not going to be quitting my current job yet – my current project is pretty critical and I would be landing them “in it” if I were to leave now. Not my style. I am formulating plans to start getting the ball rolling of Q1 2010 (following a successful project launch!).

Before that, I am keen to get some input from people out there actually “doing it” – so I have prepared some questions.. If you have 5 mins to spare and are/have been a freelancer, I would really appreciate your input.

The Questions

1. Why did you go freelance?
2. Did going freelance meet your aims?
3. What would you say is the hardest thing about going freelance?
4. What is the best thing?
5. What do you think is/are the most common misconception(s) about freelancing?
6. What tips/tools would you recommend for someone getting started?
7. Do you think I am mad?

Hopefully if all goes to plan, I can collate some useful tips and advice for others!

Thanks a lot – I appreciate you taking the time out!

Work hard. Play harder.

Kanban: “Value”, Keyser Söze and Process Improvement

With my recent foray into the world of kanban I have really been focusing (or should I say adjusting my focus) on tasks that add value.

“Value”

I think “value” is a funny word – the meaning of it seems to have been diluted/misinterpreted at some point. Many people often associate value as simply meaning “good” or “cheap”. While finding something of value is “good” and value is determined by how “cheap” it is – it is not all “value” is about.

To quote dictionary.com:

relative worth, merit, or importance: the value of a college education; the value of a queen in chess.

Note, this is the first definition, before “monetary or material worth”. For me, there are two key words in the above quote: Merit (“excellence”) and Importance (“consequence”).

Value is about striving for excellence in the most important/consequential things.

To add "value” to our lives, we should aim to perfect that which means something to us.

This is something that has really struck a chord with me. Hell it’s strung a whole load of them and my brain seems to be happily strumming away. I now find myself looking at EVERYTHING and how it adds value to what I am trying to do.

Kaizen – The Keyser Söze of Kanban

In kanban and lean there is a strong notion of kaizen. First off, we establish flow (our process). We accept that the flow may not be perfect but we establish a pull mechanism which ensures that we only move items into the next stage of the process once we have everything we need (whatever that may be).

This produces some interesting experiences. You quickly start to find that your process which you thought was bulletproof is suddenly full of holes and peeing all over the carpet. You realise you do not stick to your process as well as you thought, or your process is simply flawed and creating more work at some places and bottlenecks at others. This may sound negative, but it’s a fantastic thing.

As a software developer, I am a big fan of “fail fast”. If something isn’t quite right I want the system to fail (gracefully). A failed system highlights flaws. Once flaws have been highlighted, they can then be fixed.

Ensuring we perform a regular review of our board (I have it as the final stage of my COMIK process) forces us to go on the hunt for the elusive kaizen opportunities. The funny thing is though, much like Keyser Söze, 9 times out of 10, it’s staring you right in the face – you just need to open your eyes to the possibilities.

Making It Better

Once you have identified the problems, you can start working on the solutions. Again, with the kanban board we have the ability to change the board quickly (especially with excellent tools like Nate Kohari’s AgileZen) so we can try new things to see how they work without too much “cost”.

An Example

I recently had a fantastic kaizen brainstorm. One of the key thoughts that came to me was:

Every time I improve my process, I bite off even more. This prevents me from actually getting better at the work I do, I just stay the same level and try to cram more down the pipe.

By this, I mean that I felt I was not really adding value to the work I was doing – going through the motions does not mean you are good (or getting better) at it.

Resolution

I established strict work in process limits. WIP limits are a common theme across lean/kanban teams. It basically says “I can only do so much”. It’s not rocket science.

However, I never really applied it to my personal kanban board since I felt that “hey, I’m in charge of me and I know exactly how to manage myself!”. Well, kanban and kaizen showed me that I was wrong.

Now, I cannot bite of more than I can chew – the only way I can pull something else is if I either complete a bit of work, or re-prioritize. And that is the key – I need to make my work count. If I need to get tasks A, B and C done, but I can only do one of them – which one should I do?

The one which:

• Add the most value.
• Will make the next task easier.
• Will move a project forward.
• Make me never have to do task X again.
• Enables someone else to do task Y.
• etc.

WIP Limit Misconceptions

WIP limits are often viewed as people “trying to be lazy”. I personally viewed them as a “waste of time since I was only managing one person”. This is not the case.

WIP limits force you to be honest about how much you can get done - this ensures you to do the right things first.

Think about how much you can actually get done (to a high quality) then limit your work to that. Now take the best of the backlog and work with them. Keep the value flowing.

Work Hard. Play Harder.

Kanban: Goodbye PAIR, Hello COMIK

If you remember my recent post on Personal Kanban and the PAIR system, I have of course been running with it and seeing how it fares on the projects I have been working on.

In the constant pursuit of kaizen, I was reviewing a couple of recent work items and similar things kept cropping up. Upon reflection, I believe these issues occurred due to the all-too-common lack of quality preparation.

“Quality” Preperation?

Now, I know what some of you (software heads) are thinking.. “oh noes! massive technical specs, requirements specs, specs of specs and specs that show how weak your kung fu is”.

Incorrect. I HATE excessive documentation - with a passion.

<rant> Seriously, for the most part, heavy spec requirements are fluffy bullcrap to normally protect a crappy software dev team from actually doing what they are supposed to do and build software that provides value to the customer. </rant>

Anyway, I don’t need to go into detail on that – we know what we need to work.. Or do we?

Where Did PAIR Let Me Down?

To recall, “PAIR” was Preparation, Action, Implementation, Review. I found there was a lot of value in this since it forced me to think about doing the “right bits” in development of deliverables (not always software-based).

However, me being a geek and wanting to get to the good stuff quickly – I often neglected the "preparation”. Or the “preparation” would simply be me re-hashing what I WANT to do, not necessarily HOW I was going to do it.

So, to be fair to PAIR (no rhyme intended) it wasn’t PAIR letting me down, I let MYSELF and PAIR down. Neither of which is good.

I also found that the Action and Implementation phases were a bit of a grey area on many tasks. Is there a real distinction between the two? Does the language convey that? Who really gives a crap?!

Think, Geek!

Having a good brainstorm on it led me to the following thoughts:

I’m Crap

I know better, we all do, but at some point we decide to be crap and either turn a blind eye or “forget”. Hey, it’s not our fault, we are human right? Well yeah, but it’s still YOUR fault!

Sometimes I Need Help

A tough one for me to admit, and to be honest it’s only a little bit of help (grin). But yeah, I need help to keep me on track. I would rather swallow pride and admit it and get better right?

Sustainable Pace?

I am sure most of you know me know that I am forever working. Sure, my GTD process is constantly improving and I am getting more done, but I need to make sure I don’t just keep throwing more on to drown myself. I need to limit my new work and work at a pace that I can keep working at.

I Wasn’t Embracing Kaizen

… as much as I needed to. “Review” is simply too “fluffy”. I often pretty much just glanced at my tasks notes rather than actually take time out to think about what went good/bad and how to learn and improve on that.

Now What?

Taking the above into account, I decided it might be a good idea to:

• Break out the “preparation” into separate, distinct phases that force me to think about the the task and requirements for it.
• Focus on adding value rather than just doing tasks. Think “80/20”. This naturally reduces the amount of work that I actually then do.
• Creating a “form”/crib sheet to work through to make sure I go through the required motions, each and every time.
• Strengthen the focus of kaizen rather than “reviewing” (which can be rather “wishy-washy”).

The result? COMIK.

COMIK? WTF?

COMIK stands for Conception, Obstacles, Model, Implement, Kaizen.

Conception

This is where we write down the idea. “Save the cheerleader”, “hug a koala bear” or perhaps “make a sandwich”. The focus is to then find the value. Of the three above, the latter two may be really nice things to do, but what value to they really add? Saving the cheerleader though? Sounds pretty important. First off, you need to save her to save the world, secondly, look at her! (nom). *cough* Anyway.

Ask yourself:

• What do you want to do?
• Why do you want to do it?
• What value will that bring?
• Are you reinventing the wheel?

The last point is important – the truth is this, a lot of good ideas have already been done, check them out. Sure, your version might be better, but understanding what is already there can either cause you to save [wasted] time reinventing or better apply it to building something better.

Obstacles

Here we are simply aiming to note down anything that you will think will get in the way of you achieving your success criteria.

For me, I find these are normally things like:

• Learning a new technology.
• Me procrastinating.
• Unclear objectives/unsure of what the hell I really want.

Again, the last one is important. How can we possibly complete a task that has no real end? However, this is a common occurrence and we should accept it. It’s perfectly normal to have a cool idea and have no idea how you are going to get there, that’s where innovation comes from.

Model

Now, we have an idea of what we are doing, why we are doing it and things that are going to try and stop us. At this stage we are looking to flesh out the task until we are ready to implement.

Some points to note here:

• Coders, do not even think of writing the modelling code in your actual project. Keep them totally separate. The modelling process should be fast and messy and should never seem “Release” configuration ;)
• Keep trying new ideas until you have a good understanding of where you actually want to take the task. This can take time. Be prepared to spend it. You will get a better result at the end, it’s an investment - speculate to accumulate.
• Isolate the individual task from everything else. Most tasks are part of a big complicated project. Keep the worries of “all the other bits” away from your modelling process – unless they have specific meaning/impact. **
  
• Stop when you feel like you are looking at the solution you need.

** For example, I was recently prototyping stuff with MEF. Now, I intended to apply it to Tomato Timer (TT) so I modelled based on the TT architecture, but I did not import any of the TT code (and it’s dependencies) etc. In doing so this allows you to focus on what matters.

Implement

Now, if you have done your modelling right, this process should be relatively easy. I say relatively because there are always numerous things that may come into play when playing for real money:

• Coders, production code should be a lot more readable and robust than your modelling code. Not to mention test-supported.
• Everything needs to be documented in some way. Other people need to understand the model you have designed and why.
• Legal and compliance bits and bobs that need to be addressed.
• … any other constraints that apply to your work!

Here the focus is adding the value. Note, “value” is often misinterpreted as “cheap”. Incorrect. Value is the perception relative to the worth of the “goods”.  “Good value” is a low price for a top-quality product. We should embody that in our work. Just because we want to make things cheaply and quickly it should not degrade the quality.

Our modelling stage was for the quick-and-dirty work to make it easier to produce a high-value product.

Kaizen

Finally, I wanted to actually include the word “kaizen” since it really gets me in the mindset of improving. This isn’t a “review”, this is a really serious reflection period on how I can do things better. Even if you come up with just one thing, one tiny thing - you will find that you will quickly find lots of great ideas to get better at what you do. No matter how good you think you are.

Summary

I feel like this process falls a lot more in line with how I work. It is probably best suited to the more “project-y” tasks rather than standard “personal tasks”  (e.g. “walk the dog”) where a simple “waiting, doing, done” process works fine. This is the benefit of kanban, it’s really flexible.

I created a simple “crib sheet” which just contains the above COMIK headings. I then print one of these and write in the boxes – yes, in good old-fashioned pen - as I progress through the task.

I find this then gives me an excellent resource with which to approach kaizen. Hand-written notes as you go will be a lot more honest and display a more accurate timeline of steps completed and problems encountered along the way (scribbled out bits are a classic indicator). Noting these roadblocks can highlight key areas for future improvement and areas for study.

Separating the “preparation”out into “conception”, “obstacles” and “model” really helps me digest the task requirements before I start burning hard time on it. I spent only 1 hour completing these steps modelling MEF items mentioned earlier. I am 100% confident that if I had prematurely got straight to coding (as I would have done) I would have spent more than 4 times that amount arriving at the same place. No doubt this would be with a headache and a large amount of crap to unpick. Not good!

As always, this process can (and should) evolve. I just wanted to share my thoughts on it with you. Thoughts?

Work hard. Play harder!