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.