You and a million people other people can use the same chunk of knowledge without diminishing it.  In fact, the greater the number of people who use it, the greater the likelihood that someone will generate more knowledge with it.

 

- Alvin and Heidi Toffler from the book Revolutionary Wealth

 

The Tofflers are back with more futurism continuing their work from the Third Wave which was written in 1980.   I remember at the age of 12 reading Future Shock and all about information overload.  Coming from a small town in the Great White North of Canada, I had no idea what this meant.   Now I do.

 

But I digress, back to the quote above.  What does this have to do with software industrialization?  Everything actually.  In fact, thats the point of reusable software a chunk of software that is built upon another chunk of software that can be used by more people.  While I have accused our software industry of always writing software from first principles, commenters on this blog have pointed out that most always we write code on top of reusable frameworks or libraries.  While that is true, we still do write some of the same software over and over again (and one source code line at a time).  How many login dialogs have been written over and over again?  Customer classes?  Order classes?  You know what I mean, we are kinda stuck at a certain level of reusability where anything above framework or library code, we are back to writing code from first principles again.

 

I think the Tofflers quote also parallels Brad Coxs Software IC vision and specifically in his book, where we as programmers manufacture objects made of bits, but we still have not found a way to buy, sell and own them.  Brad has a solution which in many ways parallel what the Tofflers are talking about, yet, this industrialization of software has yet to mature to a point where it is a reality.  Aside from the distribution problem, which I will discuss in another post, I am interested in the reuse problem at the moment.

 

In my last post I discussed an idea around a design tool that reuses software components, or assemblies or classes, depending on how you see it.  Now I am going to discuss these ideas in the context of .NET as that is what I know the best, even though I have programmed in several languages (I do miss Smalltalk), I make a living as a .NET architect so this is the context I will use.

 

Lutz Roeder has a fantastic tool called .NET Reflector which is a "class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL."  In some respects it reminds me a lot of a Smalltalk System Browser or Objective-C Browser.  The point being is that I can load any .NET assembly and effectively discern its design specification.  Why would I want to do that?  Well, if I want to reuse a piece of software, then I want to know what it has to offer so I can discern whether I want to reuse it or not.  Moreover, if I decide to reuse it, I need to know what methods, properties are available to me.

 

Where am I going to find reusable software?  Well, aside from the few catalogs that are available, Google (search) has the biggest reusable software catalog in the world.  So lets say I find some components that I want to reuse.  For example, the ubiquitous customer class or assembly.   I can add a reference to it in VS2005 and start using it, lets say in C#.  But then it is only one component (or class in this case) and I then I am back to writing single lines of code again.  No, what I am talking about is collecting as many reusable classes and/or assemblies that can solve a business problem and then composing my solution out of these assemblies.  In fact the design tool I am thinking of can assemble these assemblies dynamically.  Thats the other half of the design tool I am thinking of.  One half is disassembling components for their design specification and the other half assembling the components into a finished application.

 

This is why I am really excited about IronPython, a dynamic programming language that seamlessly integrates with the .NET Framework Class Library (and any other .NET assembly and COM object).  This means my design tool can glue classes together, subclass and essentially dynamically bind objects on the fly.  Now if I could that, then all of a sudden I got a real software design tool.

 

Maybe the design tool will look like a Smalltalk System Browser where a product and/or functionality like .NET Reflector can be used to fill the browser with classes and methods from the various imported assemblies (including the .NET framework class library).  Then using IronPython as the embedded interpreter, I can add code to glue the assemblies together to produce the final solution.

 

Whats the point of this?  Well, I think that in order for software industrialization occur, we need to be able to reuse the vast amount of software components (classes, assemblies, whatever) that have already been written.  In fact, I am fairly sure that whatever your software problem is, a solution already exists (or at least the majority of components), you just have to search for it on Google.  Thats a rather sobering thought, the software you have been tasked to write, in all likelihood, has mostly been already written.   Or at the very least close enough for you to subclass or add methods to an existing class (or assembly) where you are composing applications rather than coding them from scratch.  While Quartz Composer is a GUI Visual Programming Designer that assembles GUIs with little to no coding, the same principles apply.  Software Industrialization is just a matter of time.

 

Next post, it may take a while, but I would like to prove this idea out.  First I need to learn IronPython

The thing to do with the future is not to forecast it, but to create it.  The objective of planning should be to design a desirable future and to invent ways of bringing it about.

 

- Russell Ackoff, Ackoffs Fables.

 

People are always blaming their circumstances for what they are.  I dont believe in circumstances.  The people who get on in this world are the people who get up and look for circumstances they want, and, if they cant find them, make them.

 

- George Bernard Shaw, Mrs. Warrens Profession.

 

A couple of quotes to start off this post as I was lamenting the fact that we don't have any real software design tools as described in my last two posts.  Time now to do something about it.

 

The .NET 2.0 Framework Class Library has approximately 29,000 types in it.  Many more times that has been built in the COM world, plus the .NET world over the last 10 years.  Even using Google to narrow the scope of locating a specific Customer.DLL turned up 275 hits.  Of course, not all of these are .NET or even COM components, but my point is that an incredible amount of software has already been designed at the component level, but there is no easy way to reuse or leverage these assets in the way that I want from an application design perspective.  In other words, why build a new customer class when a couple hundred have already been designed and built.

 

The design tool I am thinking of needs to be able to leverage these reusable assets.  When I speak of design time, I mean the ability for a tool to dynamically access pre-built types, subclass them, add methods or properties, tie other types together and collectively compose applications based on reusable parts with some level of coding to glue it all together.  This design tool is actually an application that anyone could use to compose their own applications using whatever pre-built types or components they wish to use in an easy to use fashion.  The design tool would be targeted at business analysts and programmers and even power users who need to build a relatively simply application where Excel is not powerful enough, but the Visual Studio IDE and C# are too complex and time consuming to learn. 

 

As a person that gets paid to architect and code in the Microsoft world, I have been following a nifty dynamic language called IronPython.  In fact, I am really excited about IronPython as the .NET implementation is incredibly reflective, exactly what I need for the type of design tool I am talking about.  IronPython is the code name of the new implementation running on .NET of the Python programming language. It supports an interactive interpreter with fully dynamic compilation. It is well integrated with the rest of the framework and makes all .NET libraries easily available to Python programmers.  Also, is happens to be open source from Microsoft.

 

To get an idea of how powerful this dynamic language is, have a look at Jim Huginins 15 minute demo on the MSDN site.   I recommend downloading the videos to watch locally on your computer to avoid popup hassles.  One interesting part is embedding IronPython in a WPF XAML application, something that I am considering for my design tool.

 

Now I have no intention of declaring IronPython better than any other programming languages or the foibles of duck typing.  What I am suggesting for my purpose in building a design tool for interface extensibility for .NET types, it could not get much better for me.  One of IronPython's key advantages is in its function as an extensibility layer to application frameworks written in a .NET language. It is relatively simple to integrate an IronPython interpreter into an existing .NET application framework. Once in place, downstream developers can use scripts written in IronPython that interact with .NET objects in the framework, thereby extending the functionality in the framework's interface, without having to change any of the framework's code base.

 

IronPython makes extensive use of reflection. When passed in a reference to a .NET object, it will automatically import the types and methods available to that object. This results in a highly intuitive experience when working with .NET objects from within an IronPython script.

 

Perfect for my design tool scenario. Next post, what this design tool might look like.