Scott Hanselman just wrote an excellent post with a photo when he was a child geek.

I cannot resist following him
This 1985 photo gives a good idea of the little nerdy I was. Second row from the bottom, 4th from the right.

I was ten and I was playing with my first computer, an Exeltel (a french computer)! At that time my main programming activity was to tweak strings and redefine the character set, all this in real-time, to do the games my computer didn't have, like the so cool Sega Space Harrier. Without the 2x68000 the arcade machine had, I needed a solid imagination to enjoy playing with my own version. The same year, our school got a dozens of Thomson Mo5 and it was fun teaching the teacher how it worked. A few years later, the next step was to code 3D demos for Commodore Amiga. Everything was programmed with 68000 assembly and had the constraint to display 50 frames per seconds.

Everyday my mom was angry telling me computers won't help going anywhere in life  Hopefully my friends and parents made me discover also the pleasure of socialization and outdoor activities.

Since then, my only break in programming was when I did a few years of advanced mathematics classes. I really love maths, especially theory of numbers, but didn't imagine what to do with it except teaching. I didn't realize all the potential of being a financial trader. So I chosed to quit maths and go back to software. And since recently, I think my choice of being a programmer instead of being a trader, was not a too bad choice. Especially that for more than 20 years every programming day is playtime .

I announced this on Twitter a while back, but I've left my full-time job at Xclaim to join VersionOne as their internal Agile Development Coach.

I'll say, leaving Xclaim was kind of a bittersweet thing. I'm still a part owner of the business, which is nice, but it's the excellent team and practice we've forged together that I'll miss the most. I get really involved in my work and it was at 5:00pm on my final Friday that I was feeling, let's say, like the ultimate chicken.

I'm comforted, however, by the fact that Xclaim goes on and continues to be a great team. Every coach needs a captain, and my colleague, Rik Bardrof, is more than ready to take on the next set of challenges. He's in cahoots with the same awesome and dedicated people I had the pleasure of working with over the years and I'm positive they'll continue to kick it, as they say, up a notch.

For those that don't know, VersionOne makes tools for Agile teams and organizations. In fact Xclaim is a happy customer. My job there, as the internal coach to their development team, is to drive new practices and process improvements that can help take them to the next level. What's cool is that they've got an already-rocking team right now. In the course of a day long interview/visit, I got a sense of clear vision from top leadership and met some very talented, passionate team members. All the ingredients for a legendary team are in place and that's something I knew I had to be a part of.

I took the job for another big reason: the domain is really interesting. You're working to drive continuous improvement on an Agile team working on a product for other Agile teams. How meta can you get?! I quite like the challenge of serving both domain expert and playing coach roles simultaneously. This team will push the edge of Agile and Lean to the point where we can harvest and validate innovations and bake them into a product that sells itself. This has to be the highest form of technical excellence a product team can achieve. I believe that's within reach, and am looking forward to sharing our experiences along the way.

I told a condensed version of this story on Twitter but it bears repeating in a more rambling format.

We replaced the reverse osmosis system on our water at home today. Old unit worked well enough I think but was crazy noisy and it was always a crap shoot to be able to get someone out to do maintenance on it. The maintenance schedule itself was up for debate depending on who answered the phone at the place where it was originally purchased.

We replaced it with a unit recommended to us by our plumber. I like our plumber a lot not because of his skill, of which I have no point of reference to judge, but because of his passion. The guy loves talking shop when he's onsite. Whether it's upping the water pressure in our faucets by removing the flow restrictors (I recommend it for showers, not so much for sinks) or rating the options for new fixtures on our bidet (I bet you think I'm kidding about that one), he always talks with an enthusiasm that's infectious. Which is why I use him.

So he shows up today and is busting at the seams with excitement, waiting to show me how the system works. As soon as he stepped in the door, he started opening the box like a kid at Christmas. And I should point out that this is not a small man. He's at least 6'4" and, shall we say, "sturdy".

At this point, his eyes gleaming, he goes into the features and how it works and whatnot. He starts talking about intake valves and de-ionization filters and membranes and sediment and parts per thingy and pressure whatsits and quarter-inch flibberygibbits. All with as much crazed energy as you can stuff into a 6'4" plumber.

As my eyes glazed over, it occurred to me: Is this what I sound like to users?

Energy, enthusiasm, and passion are awesome pre-requisites, but let's not forget that we still have to talk to people. As easy as it is to dump "Excellent communication skillz" on your résumé, it pays off in dividends if you actually mean it.

I'm not exactly an expert at communication. But I'm anal enough about it that my daughter is going to hate me when she hits high school English class. And I do lament the gradual laxing of rules with the proliferation of IM and Twitter.

I like the power communication has. I love the way you can change perceptions by wording something differently. In my experience, choosing appropriate language is almost as much a predictor of success as the actual code. That's in your written documentation, your formal presentations, and in our everyday interaction with users *and* developers alike.

To tie this back to my plumber, when he was done his verbal throughput on all things RO, I just looked at him like a good user and said: Whatever, man, just make it work.

Kyle the Reversed

Today we launched an exciting project on CodePlex, namely the Common Service Locator library. What is it? It's a shared interface that applications and frameworks can reference in order to leverage IoC containers / service location mechanisms without taking hard dependencies.

The dominoes all fell like this. It all started with Jeremy Miller's post. This then spurred on Ayende to send an email to a bunch of folks including many of the leading IoC container authors including Chris Tavares who wrote Unity, and myself (no I haven't written an IoC container yet :)) Next thing you know we're all designing the new library over email over a period of several weeks.

You can read more on this at Chris's post here.

If you download the library you'll find the following interface.

namespace Microsoft.Practices.ServiceLocation

{

    public interface IServiceLocator : IServiceProvider

    {

        object GetInstance(Type serviceType);

        object GetInstance(Type serviceType, string key);

        IEnumerable<object> GetAllInstances(Type serviceType);

        TService GetInstance<TService>();

        TService GetInstance<TService>(string key);

        IEnumerable<TService> GetAllInstances<TService>();

    }

}

You'll also find a static ServiceLocator class that exposes an ambient (current) container. This provides a convenient way for frameworks to grab access to the current locator. It allows you to provide a delegate which will get invoked to retrieve the current locator.

namespace Microsoft.Practices.ServiceLocation

{

    public static class ServiceLocator

    {

        private static ServiceLocatorProvider currentProvider;

        public static IServiceLocator Current

        {

            get { return currentProvider(); }

        }

        public static void SetLocatorProvider(ServiceLocatorProvider newProvider)

        {

            currentProvider = newProvider;

        }

    }

}

So how many people did it take to design such an API? Well let's see eight (no this is not a bad joke). The beauty is that those people represent a collaborative design effort both within and external to Microsoft. Yes, we all reached an agreement!

In addition to the this interface, you'll find several adapters for IoC containers available with more on the way. I'll be adding one for MEF (which is a locator) to that list shortly.

Also you'll find a suite of unit tests you can use to validate that an adapter meets the functional requirements of the locator interface. We can thank Oren for that contribution :)

Our hope is that this interface will encourage products and frameworks to start leveraging IoC / Service location now that we're removing the need to depend hardly on a specific one. The community can make this hope a reality ;-)

MEF is going MS-PL!!!

Several weeks ago, we shipped our first drop of MEF on CodePlex. The source license for that drop was MS-LPL or the Microsoft Limited Permissive License. This license enables the source to be freely used on the Windows Platform.  Obviously, we don’t ship everything under MS-PL. In the case of MEF, it was our long-term plan because it made sense for us to do so, especially because it had the potential for universal appeal, including for cross-platform use.  Shipping MS-LPL was the easiest way for us to quickly get MEF out the door as we worked through some details.

Once we shipped we heard a bunch of feedback from the .NET community, including from Miguel De Icaza, founder of Mono. The crux of the feedback was that they wanted MEF licensed under an OSI-approved license, such as the MS-PL.  We have listened to the community feedback and are accelerating our efforts. Thanks for caring!

When / How?

It's already done! As a matter of fact if you check CodePlex, you'll see we're already there, and have released new source. There are two caveats to this move.

• There is a piece of code that MEF currently depends on which we are not planning to ship as part of MEF's official release in the framework. For the current drop we have ripped this source into a separate System.ComponentModel.StructuredValues.dll which the new MEF source references and which is still under the MS-LPL license. The rest of the source that references the dll (which is 99% of MEF) is now MS-PL.
• In order to put the new license in place, we've needed to purge the old releases and source. This is because Codeplex projects can't have source drops with 2 different licenses simultaneously.  Fortunately you can have one release that has 2 licenses as this one does. :-) Special thanks to Sara Ford and Pete Coupland for their last-minute after-hours fire-fighting jedi skills to get the purge done and the license change so we could get out the door.

We are doing this interim drop with the dll as a stop-gap measure. In the next full drop, which will be in about 3 to 4 weeks,  this dll dependency will be removed from MEF completely and the entire drop will be MS-PL.

Why not wait?

We could have waited and not done this interim drop. That would have been the easiest, and we would have had less explaining to do ;-) We chose not to wait based on your feedback. We want you to know that we heard you and are doing something about it. We want to show you sooner rather than later that we mean business.

What does all this mean?

It means you can grab MEF's source and use it on whichever platform you like!

If you take the source you are also free to fork it. MEF ships in the .NET Framework so we are going to be super responsive to customer asks. We hope that forking is not needed however it’s nice to know that it’s an option if necessary.

Go get it here: www.codeplex.com/MEF

I was very happy to hear the news that Amazon will be providing Windows/SQL support on their EC2 cloud computing service. From the email announcement:

We are excited to let you know that Amazon Elastic Compute Cloud (Amazon EC2) will offer you the ability to run Microsoft Windows Server or Microsoft SQL Server starting later this Fall. Today, you can choose from a variety of Unix-based operating systems, and soon you will be able to configure your instances to run the Windows Server operating system. In addition, you will be able to use SQL Server as another option within Amazon EC2 for running relational databases.

I've been waiting for this option. For a long time the LAMP stack has held a distinct (and unarguable) advantage in long tail plays; much easier to find the kinds of virtual, on-demand models associated with "cloud computing." With this, I see that gap narrowing.

Even so, during this time of low availability, new architectures might have had a chance to sneak into the (at times monolithic) .NET developer community. When we reach for a persistence solution for our next killer web apps will it be SQL Server 2008 or a distributed hashtable?

The October meeting for DC ALT.NET will be on October 21st, 2008 from 7-9PM.  Check the DC ALT.NET site and our mailing list for continuing updates and future meetings.  This month, Linda Cook will be presenting "A Look at Kanban Software Development".  I've been exploring a lot of Lean Software Development and Kanban, and this is an opportunity to explore the topic in depth with an established Lean/Agile coach.  My CodeBetter compatriot, Dave Laribee had introduced Kanban to XClaim Software and has some really good information on the topic.

About Kanban Software Development

Kanban is gaining popularity thanks to a growing number of groups, including Corbis and Yahoo!, who have been practicing and learning how to best apply Kanban to software development projects.  Kanban uses lean techniques, such as queue management, flow control and theory of constraints to optimize the workflow of a team.  As David Anderson states, "Kanban is a process that exposes the natural workflow of a system and reduces lead time by limiting the amount of work in progress."

As part of this discussion, we'll look into what it means to use a Kanban system for software development and how to apply the "pull based" system, which determines the supply, or production, according to the actual demand of the customers.  Comparison and contrasting between Kanban and Scrum will also be discussed.  Kanban systems use constant inspection and adapting techniques to identify bottlenecks and defects.  Linda will share her experiences using Kanban and how it helped the team collaborate on a variety of projects.

About Linda Cook

Linda Cook is a Lean/Agile Coach with over twenty years’ experience in the IT industry. She mentors colleagues, creates formal and informal training programs, and helps organizations apply some of the best practices in the Lean Software Development and Agile Project Management. She is a Certified Scrum Master and completed the Lean Six Sigma program at Villanova University.

Details

The details of the event are as follows:

Date/Time: 10/21/2008 - 7-9PM

Location:
Motley Fool
2000 Duke Street
Alexandria, VA, 22314

Hope to see you there!