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.

 

I came from the R&D electronics engineering world in the 80s and got into software development in 1991.  After 15 years in the software dev biz, the only conclusion I can draw is compared to the industrialized electronics world I came from, the software development world is decidedly unindustrialized.  In addition, we are going backwards instead of forwards in our progress towards industrialization.  I am genuinely concerned about the future of our software industry.

 

Nonsense you say?  Let me put some context and perspective around my statements.  In the 80s when I was still in the electronics engineering world, software computer programs (i.e. CAD/CAM) were on their way to the top of the Technology Adoption Curve,  particularly with the release of AutoCAD in 1982, which soon brought a level of design automation to the electronics engineering world that was literally revolutionary.  I lived it.  Here is a concrete example of what I experienced.  Instead of handcrafting printed circuit board layouts by hand, within a couple of years, we were operating several sophisticated computer (i.e. CAD) programs that could assist with the design of the layout of the board cheaper, better, and faster than I could do it manually.  What the CAD programs didnt have was my experience so in the hands of a skilled and experienced operator meant the ability to put cheaper goods, with much more quality in the hands of consumers, faster.  It also meant some serious electronics industrialization has happened over the last twenty-five years - almost feels exponential in my opinion.

 

I used the term unindustrialized in the first paragraph, what do I mean be that?  I mean that in our software development world, we do not have any (real!) predictable or repeatable processes for the specification (i.e. design) of software.  And please dont tell me about yet another great process methodology**.  Worse yet, when we do design and construct a software artifact, it invariably is the wrong thang.  We also cant scale in anyway to design large scale architectures.  Finally, our software development world today is based upon designing software from first principles, rarely do we leverage other peoples excellent work, including CAD systems and/or approaches that worked in other, now industrialized industries (e.g. electronics).  I see the latter being the biggest hurdle to overcome as it is a cultural change instead of a technical one.

 

** Note In 1995 I worked at Eastman Kodak in Rochester, NY.  Kodak Equipment Commercialization Process (KECP) was a new product introduction (NPI) process methodology that has evolved for decades we have nothing this evolved in our software world.  Further, some would say that in order to make a process predictable and repeatable, you need to be using the same tools over and over again or at least for a period of time to establish a baseline and then a feedback loop.  Our software tools keep changing every six months (or earlier), so we cant even establish a baseline let alone a feedback loop  Kodak knows a thing or two about industrialization and we in the software industry could learn from that.

 

What do I mean by going backwards?  I feel that we are going backwards in two areas, programming languages and more importantly, design environments that can produce design specifications, and no I do not mean CASE tools.  We are woefully lacking Computer Aided Design tools that are now best practices (and have been for years) in other industrialized industries like electronics, manufacturing, building construction to name a few.  Do you think it is unreasonable of me to expect better software design tools when I was handed exponentially more powerful tools in the electronics industry years earlier?  Thats my gripe, still hand crafting single lines of code after 15 years in the industry.  Something is wrong, man!  Maybe I am real naive or born in the wrong era, but you would think that we in the software industry, after 15 years (try 30!) could come up with better design tools than a glorified text editor, now mockingly called an Integrated Development Environment.  No?

 

So, programming languages, how can I say we are going backwards?  Preposterous!  Well, whatever happened to Smalltalk?  Yes, every programming language is a foreign language, some easier to learn than others and thats my point.  Have a quick read of this short article from 1991 to see what I mean.  From my industrialization perspective look at how incredibly simple and efficient Smalltalk is!  The language consists of 5 keywords (Java and C++ have +50) and the entire language specification can be expressed on a single sheet of paper!  Isnt this the pinnacle? The state of the art?  Its language roots are +30 years old and seem to be one of the most mature programming languages available.  What happened?  Not only was the language simple, but the development environment was equally as simple along with the most seamless source control I have ever worked with.  Again, what the heck happened?  Whats wrong with Smalltalk?  No, I dont mean strongly typed versus dynamic or VM or GC or anything technical.  I mean is it because our industry is so immature we cant see a good thing when we see it?  Is it because our industry is dominated by a handful of companies which dictates the software programming languages market?

 

The multiple programming languages I use today and the IDE I am in are far more complex by at least an order of magnitude.  Further, rather than optimizing a language that is simple to learn and effective, we proliferate choices for the sake of choice, nothing technical here.  I know of one vendor that supplies 7 different graphical user interface technologies, each complete with its own framework class library and even more IDEs.  7 UI technologies from one vendor?  How is this making it easier (for anyone)?  How do I know which one to choose?  How do I become expert in any of them, as I still need use my primary language (C#) and another incredibly large framework class library, .NET 2.0.  If anything, it is getting harder and harder to develop custom applications, not easier.

 

XAML is a brand spanking new declarative programming language from Microsoft.