OK, so what exactly is "The Box?"

I typically have always tried to "think outside the box." It's something my father taught me to do…

He said: "When you feel trapped, you are probably only seeing the possibilities that exist inside the box you are trapped in."

What he meant was that if I am enclosed in a box, then I only see the 6 walls of the box. 

Imagine if you will that you wake up are truly trapped in a box, it’s dark and you don’t know how you got here.

I feel around and all I perceive are what appear to be 6 solid walls, there are no windows, no door, no openings at all in which to escape.  So how to I get out?  I don’t know that the box is just cardboard and I can probably just punch a hole straight through the wall… But, this would also mean destroying the box.  Now we start on a journey of exploration to find a way out.

I push up on the ceiling and the box opens, the ceiling is not actually solid, but rather folded over as to look solid but really isn’t; I have just escaped without destroying the box. XYZZY.

Yes, this is just a simple analogy and not really “The Box” I want to talk about.

Software development is a tricky thing.  Many, many very smart people have created many things that we use every day to get a job done.  These are very similar to the box I just described above; they lack documentation(in the dark), they are incomplete(no door), or they just work differently than we want to(the maze).

Do you feel trapped in your development? I know more frequently than not, I do.

• When I am programming in a specific language, I feel trapped by the language.
• When I use a Framework, I feel trapped by the Framework.
• When I use a "3rd Party" tool, I feel trapped by it's limitations.
• etc., etc., ad nauseum

These are all in their own right, boxes.  They are boxes of ideas that someone created to assist in crafting software.

Lets take that a step further:

Facebook is a box, it’s a container that can import an application based on some contract.  It’s very popular because it is useful for telling all your friends about something without having to call each one of them and repeating the news.

iPhone is a box, it’s a Swiss army knife for communicating and it imports useful applications.

XBox is a box that plays games and does some other interesting things, it too can import useful applications.

In fact, a Browser is a box too, it imports these things we call URLs that might be some text, a picture, or even a guided application to do useful work.

THESE are all “The Box.”

We are trapped in them, when I am writing something that is useful in one box, it’s not necessarily useful in another.

Alright, so who cares.  I care.  I care because the way we are writing software is all wrong.  It’s wrong because we are stuck in the mentality of “The Box.”

So what can I do about it?  I’m just some guy with yet another opinion of how it should be… but isn’t.

Maybe, but I am also someone who needs to get his job done every day.

Enough Philosophy, get to the meat.

What if we could create software in such a way that gets rid of many of the limitations of our boxes?

How do I avoid just creating another more elaborate box?

We can, and we will be discovering and re-inventing exactly what that means over the next several years.

Java coders hate C++ coders, C++ coders hate C# coders, C# coders hate VB coders, and the Ruby coders just think they are better than everyone else :-)

Can’t we all just get along?  Probably not, but this is the world we live in.  Everything is divergent. Its going to stay divergent so we just need to find a way to work within those boundaries.

One thing I do know is that if you live and work in a Microsoft Technology world, there is some help for you within that quite large world of development.  This is “The Box” I am going to be focusing on.

Typically, we are writing software that follows some pattern or another that is sometimes referred to as a “best practice.”  Most of these “patterns” come from the Java world not because Java is the best, but simply because academics who write this kind of stuff decided they would use Java.

So can’t we have some patterns that are our own?  Of course we can and the first of those patterns I am going talk about in my next post is “Composability”. Hopefully you know what “Inversion of Control” and “Dependency Injection” are and what purpose they serve.  I am not going to go into describing them much more than to say, they are great for things you know everything about.  For things you know nothing about, not so much. Composability doesn’t really have much to do with this, except that to get it, you don’t need IoC/DI.  Closely related to Composability is “compositionality.”

The idea of “The Box” is that it’s a trap and what I really want to do is introduce you to a methodology that reduces the possibility of really getting trapped.

Inversion of Control is all about reducing the procedural nature of programming.  When I started programming, we wrote programs that started and ended in a line by line step of procedures.  This is procedural programming and for the most part, we are still doing it. We have reduced the amount of procedure to a smaller set of steps, but in fact, it’s still procedure mentality.

Dependency Injection is all about decoupling one part of a software from another.  This means that if I have two procedures, they don’t depend on each other for my application to function.

Yes, this is the skeleton of what IoC/DI really mean, but that all we really need to know.

My goal now is for all software to become Composable and have compositionality.

How can I achieve this “Holy Grail?”  I use the grail analogy, because we can’t at this time start on the quest to find the solution for everything. 

The constraints of my box:

My box is going to have the following constraints:

We write software using the .Net Framework.

Wait, That’s it?  What about Silverlight, Web, Windows or whatever choices we make?

Yes, those too add some limitations that may be unique to some of your needs, but the style of writing and the methodology is the same, this applies to them all.

But IoC/DI is all the rage!  Why would I abandon those?  I’m not saying you should.

I am focusing specifically on writing NEW software, if you need to conform to anything legacy, you can write the new stuff with this methodology and still use it inside a box that contains your IoC/DI limitations.

Alright, next constraint.

We will be using MEF, the “Managed Extensibility Framework” and the Reactive Extensions for .Net.

Yes, these are new, they are not for everyone(yet). If we start designing and thinking outside the box of what we have been taught for so long, you may start to see there is a way to break some of the chains that have constrained us elsewhere for so long.

I really look forward to digging into this and hearing your feedback about both the patterns and the idea of composability which will just change the way we think about writing software in the future.

We will start simple, we will be building a Framework from the ground up using this methodology one piece at a time and looking at how each part works so we can apply it to our own business needs.

Design Outside the Box with MEF and Rx

This is probably one of the most important videos I have watched this year.

DICE 2010: "Design Outside the Box" Presentation Videos - G4tv.com

In it Jesse Schell, a professor at Carnegie Mellon University talks about the emerging economy that is coming from Gaming.

Facebook game companies (Farmville) sell for $350 Million Dollars, WiiFit made $1 Billion Dollars… Seriously?  Yes, Seriously.

So what does that mean should I just start writing Games?  Well you could, but the real take-away for me was that technologies by nature DIVERGE.  There has been so much prediction about convergence over my career one thing I can assure you of, it will never, ever happen, at least not in a free market economy.

This means that I need to be prepared in whatever software I am writing to be able to adapt quickly to both changing needs and changing systems.

Technologies such as MEF – “Managed Extensibility Framework” and Reactive Extensions for .Net (Rx) are going to become ESSENTIAL tools in your toolbox.

Why MEF?  because we are going to need to extend apps without completely rewriting things, share lots of components between apps and add new functionality on the fly… MEF not only enables this, it makes it so you can create a completely composable application built from a bunch of independent parts.  3rd parties can use our Contracts and add functionality too.  This is going to be extremely important in the very near future.  We’ve been headed down this path for a long time, composability is what makes it now even more compelling.

Why Reactive?  Because our software is really going to really start living in a push based ecosystem… grab data from a source somewhere out in the ether and do something with it when I get it.  Rx makes coding this much easier than trying to manage it with a pull based Enumerable mentality.

Pull based stuff is great when you have a few components and know when you need to grab data, but what if you don’t know, or don’t care when and if you receive it… Reactive makes this style easier to manage.

If you aren’t building all your new Applications as Composable Components, then you are shooting yourself in the foot.  It doesn’t matter if they are Web Apps, Silverlight or WPF, they should all still be components so you can manage, test, extend or replace them much easier than trying to complete a working system that is even loosley coupled with IoC.

Composability is key.  “Composable Parts export services that other Composable Parts need, and import services from other Composable Parts… Composable Parts are either added to the container explicitly or created through the use of catalogs.”

This lets us create a shell and just start adding things to it, some will be complex things, what does the thing do? The shell doesn’t care, it just creates one and makes it available.  How does it interact with another thing?  Reactive makes this easier to manage through some Contracts coupled with MEF to compose them.

The Video above talks mostly about how gaming is going to pervade many things; essentially what it is really saying is that all these little composable parts are going to be interacting with each other.  Your apps need to be prepared for that, How?  MEF and Rx!

Learn them, Love them, Give feedback, because you are probably going to be using them constantly (or wish you had) from now on.

I am starting a series of posts based on exactly this, how is this new architecture going to work?  How do I build Real-world Apps with it?  Precisely what I am going to be covering as I go from the ground up to put the puzzle pieces together.