Posts

Showing posts from September, 2009

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 m

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

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

Image
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 ch

Kanban: Goodbye PAIR, Hello COMIK

Image
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