MEF is not An IoC container; but MEF uses IoC

Somehow I got on the conversion of MEF while chatting with Glenn Block.  IoC came up in that conversion.  I believe, at some point, I said something along the lines of MEF is not an IoC container; but MEF uses IoC.  Someone else asked me to clarify that after the conversation.  It’s a common misconception that MEF *is an* IoC container.  I thought it might be useful to summarize those conversations for others.

Part of what gives MEF the ability to do what it does is most certainly IoC.  Traditional dependencies (control) are inverted so that something (the host) doesn’t depend on a concretion (the extension, in the case of MEF) but an abstraction.  The abstraction with MEF and IoC is an interface.

MEF manages extensions—dependencies—that may or may not exist at run-time but are rarely known/exist at compile-time.  This needs to occur because you want 3rd parties to extend your application (of course, conceivably you must produce and publish your application before a 3rd party can even conceive of extending it).  For any one dependency, MEF may be managing multiple extensions.

The difference with an IoC container is that it’s managing static dependencies: dependencies that must exist at compile-time in order for the application to correctly run at run-time.  The impetus of IoC is different than MEF in that you don’t want to offer the ability to “extend” your application, but ensure that a particular class doesn’t have a direct coupling (or dependency) on another class.  IoC doesn’t remove the dependency entirely, it just means the code can evolve independently.  For the application to run correctly when deployed, it depends on ClassA being injected into ClassB at some point for that to happen.  But, ClassA can compile without ClassB.  This is always a one-to-one dependency.

If MEF were truly an IoC container then you’d expect be able to use an IoC container to extend an application at runtime—which is not the case.

Women in High Tech

I know a lot of really good people in software development from around the world.  I’m fortunate to have spent face-to-face time with many of these people.  These people bring great value to our industry.

One thing that was apparent again at the MVP Summit is the heavy male attendance on the software development side.

The point was made a couple of times and some tweets flowed about it a few times.  Is it a good-old-boy’s network?  Are software development leaders dominated by the “Alpha Male”.  Are women simply not willing to put up with any of us?  I personally don’t know.

What I do know is that, as a community, we’re not better off for it.  Women bring a sense of communication that is lacking by many men in the software development industry.  MVPs are generally exceptional in this respect; but they’re not immune.

I have a couple of challenges of my readers.  I challenge my readers to foster and mentor more women in software development.  I also challenge my readers to help point out women in software that should be

If you know a woman in high-tech that you believe should be recognized just as much as any “Alpha Male”; please point them out.  Use this blog if you like, or call them out on your own blog—detail why you think they’re leaders in our industry and deserve recognition.

kick it on DotNetKicks.com

What is Data-Driven Design

Data-Driven Design is a process of designing software structure and functionality.  Data-Driven Design infers functionality mainly from the information that the software is meant to maintain.  The functionality of the system focuses on having to create, view, and update that information.

Data-Driven Design is useful for designing data models and designing database schemas.  The definition of data and the structure of a database is solely focused on the data it models or contains.

Data-Driven Design differs in focus from Structured Design, which focuses mainly on what logic needs to be performed by defined how the logic changes program state.

Nourishing Technology and product communities.

Software technology and products have had a fairly unique attribute until recently: communities.  Software technologies and products have had this seemingly innate ability to have a group of people rally together about the product.  This community is a positive thing for the product: it provides technical (an sometimes emotional) support for the product and promotes and evangelizes the product.

With the maturity of online social “platforms”, many non-software products are trying to build their own communities to reap the benefits that software product communities have gains for so many years.  This trend simply validates the importance of product communities.

So, how can a company nourish and maximize the benefits of a product community?

First of all, we’ve touched on some of the benefits of these communities; let’s detail some other benefits:

  • Free technical support personnel—users helping users
  • Free promotion—comfort of real-world users to potential customers
  • Highly focused and vetted feedback—users-helping-users point out documentation/usability short-comings
  • Free Quality Control—users-helping-users point out flaws and workarounds.
  • Product developers feel empowered and more like contributors.

Some of the side-effects of the benefits include:

  • Increase sales
  • Reduced support costs
  • Increased quality
  • High ROI for product development because it’s more focused to user need.
  • Reduced product development costs.
  • Improved employee morale.

Clearly an established community  is positive to the bottom line.

Knowing what some of the benefits are, we can focus efforts on maximizing those benefits.  Without some way for a community to gather and communicate there’s no way for the community to provide any sort of support for fellow members.  The ability to community members to gather provides the ability for the community to openly discuss the benefits of the product and the different ways to use the product to solve problems.  This positive community communication promotes the product by providing potential customers with real-world solutions to their existing problems and details how to use the product to realize those solutions.  A positive community also puts a human face onto the product and company that potential customers can associate with.  Recognizing community leaders categorizes and prioritizes users and their communications.  Community communication provides tangible feedback about the product and company that can be mined at any time and vetted by category.  Employee involvement means the company is more personal and provides employees with a sense of belonging and empowerment because they see the human factor of their work.  Employee work into the product is of higher quality because employees see the human impact of what they are working on and have a sense of belonging.

Nourishing Community Guidelines

  • Community is not a replacement for technical support.
  • Provide an identity for your community.
  • Provide an presence for your community.
  • Provide top-notch technical support.
  • Be open about the future.
  • Provide a positive feedback collection mechanism.
  • Organize, prioritize, and cultivate feedback.
  • Treat your community efforts as a product.  They need technical support, to be user-focused, high-quality, reliable, robust, easy-to-use, and provide a positive experience.
  • Provide recognition for community super-stars.
  • Rapidly improve product to promote positive community communication.
  • Employees should be tasked with and regularly communicate with the community.

kick it on DotNetKicks.com

The weather outside is frightful

With news and Twitter reports of snow coming to the mid and eastern parts of North America, I’m reminded of when my family moved (temporarily) from Canada to St. Louis Mo. (okay, really a suburb of St. Louis).

St. Louis is a Midwestern city in the United States.  As such, it gets a “different” amount of snow than we were used to.  Sure enough, the first few months we were there it snowed.  Nothing major in our books.  About 6 inches, if memory serves.

Well, if our neighbours hadn’t thought this was some sort of natural disaster!  At the time, St. Louis (or at least he municipality we were in) didn’t have snow ploughs.  Well, as you can imagine, if there’s no way to get rid of 6 inches of snow (and no one really gets winter tires) everyone was at a standstill.  As I recall, we still had snow tires on our Cutlass Sierra; so, we proceeded to drive around to do whatever we needed to do.  Going to the grocery store was a bit of a waste of time because the shelves were bare.  With news of several inches of snow, everyone bought whatever they could get.

We took it in stride and strapped on our cross-country skies and skied around the neighbourhood.  I found out later that people were looking at us out their windows wondering why these crazy people were outside risking their lives!

Of course, schools were closed and businesses were shut down until the snow could be removed.  I think it was a full two weeks before they procured some ploughs to stick on the front of garbage trucks to motor around the roads getting snow off them.  We had to spend an extra 20 minutes a day in class to make up for the lost time at school.

Returning to Canada (Ottawa), I can only remember once when schools were closed due to the cold weather.  And it was due to the temperature being –40 C.  I can’t begin to count how many times we’ve received over a foot of snow, simply shovelled/ploughed it out of the way and gone on with life.

Anyway, good luck to those areas of North America that can’t handle a significant amount of snow.  Believe me, it’s survivable.

The Difference between an Anti-Pattern and a Code Smell

I think the term “Anti-Pattern” is being over used.  There’s various definitions for Anti-Pattern like “obvious but wrong, solutions to recurring problems” and “common approaches to solving recurring problems that prove to be ineffective”.  All definitions have a common thread: they’re recognizable solutions (pattern) that don’t work in at least one way and should never be used.

This means that anything that does work, when used correctly, isn’t an Anti-Pattern.  Transitively, that doesn’t make incorrectly used Patterns Anti-Patterns.

Code Smells, on the other hand, are defined as “…a hint that something might be wrong, not a certainty.”.

I’ve seen the term Anti-Pattern used in a couple of places lately that describe scenarios where patterns are used incorrectly.  Each and every pattern has a time and a place (a context).  Outside of that context, it is not an anti-pattern.

The term Code Smell is much better to describe inappropriate uses of patterns.

For example, Mark Seemann recently blogged that Service Locator is an Anti-Pattern.  I disagree.  I argue that there is a time and a place for Service Locator.  Incorrect use of Service Locator is definitely a code smell—it’s an indication (a hint, not a certainty) that there’s something wrong with the design.  The fact that you’re using Service Locator instead of Dependency Injection is, indeed, a design issue.  But, dependency injection may not be possible.  WebForms, for example.  I can’t inject dependencies into a web form because I have no control over it’s construction.  I’m forced to either use a Service Locator or a Factory to aid in my decoupling efforts.

 

 

kick it on DotNetKicks.com