 Monday, January 01, 2007
After a 6 month hiatus from the blogosphere, I am back. Well, almost 6 months. On July 17th, 2006 I proclaimed that after 80 posts on the topic of software industrialization, I did not have much more to say about it. Today I do.
Before I dive into the post about what I think the best new programming language released in 2006 was, (the language isnt new, but the implementation is), I want to take a slight detour. I have a confession to make.
The confession is that I fell into the pervading consciousness of some in our software development industry where cynicism, negativity and ego rule. One reader of my blog, (bless you Martin Danner) said that my recent posts conveyed a sense of frustration, cynicism and downright hopelessness. Martin told me to cheer up, all is not lost and in fact the seeds of change have sprouted. Thank you Martin, you were right. I was spending way too much time reading posts from: Mini-Microsoft, Joel Spolsky, Steve Yegge, Jeff Atwood, Rands in Repose, TheDailyWTF, etc. Regular readers of these authors know what I mean.
Now dont get me wrong here. I have a lot of respect for these very smart people and mostly what they write is well written, entertaining, and even thought provoking. However, there are times where each of them have also succumbed (in some cases, more often than not) to the cynical world of Dilbert software development where everything is a rant or complaint or WTF! You would think you are reading Dennis Miller Rants.
I will be the first to admit I have done my fair share of that in the past and on this blog. For those of you that knew me when I ran my own software company, I could be the darkest, most cynical you-know-what in the world. So whats changed? I realized that after 15 years in this biz I could just be yet another cynical puke or I could do something positive for myself and the software industry I work in - like contribute an open source project of some sort that would make the process of designing software more predictable and repeatable than it is today (i.e. the industrialization of software). I started that quest over 6 months ago and may take a year or two to finish. But thats another post and not my point.
The point of this digression is that I am a bit disappointed in the Joel Spolskys, Steve Yegges and the others I mention above, of the world. I am disappointed in that they could really influence the positive direction of our software development industry, rather than b*tching and stitching, in a well written manner about how everything sucks. I know some of it is not to be taken seriously, but at the same time people look up to these industry thought leaders. How is this constant barrage of negativity going to help our industry?
Do you understand what I mean? I try not to take myself or my work too seriously, but I do. I cant help it. And neither can most of the programmer types I have worked with over my software career. Its simply who we are and it is interesting to find other like minded people have chosen this profession.
So what does that have to do with the best new programming language released in 2006? A lot actually. I find it an uplifting story where Jim Hugunin, 3 years ago, started to think about ranting on why the .NET CLR would be a terrible platform for dynamic languages. Three years later on September 5th, 2006 an open source programming language from Microsoft called IronPython was released. Having played with IronPython for six months, it gets my vote for easily being the best new programming language released in 2006.
Why? My criteria is very simple. What is the simplest way, or to phrase it differently, the most productive way to write a windows program? (e.g. ASP.NET web form, WinForms, or XAML WPF). Here is an example:
Note while the least number of code lines count to a certain degree, it is the simplicity that matters the most. What could be simpler than opening an interactive console window and typing in, line by line, almost English sentences while getting immediate feedback after executing each line. Either the line you executed succeeded or failed. I love when decisions are binary. In fact, by line 3 in the example above, you already have a real live active WPF window being displayed on the screen, so now it becomes mostly a visual experience. Who needs testing? The testing is built right in, in real time either the window displayed or it did not. I know I am being simplistic, but perhaps our programming world could do with more simplicity. I have over 10 years invested in learning the Visual Studio IDE and even with James Averys most excellent book, Visual Studio Hacks, I still only know maybe 60% of the complex features of VS2005.
The reason I said most productive is because I believe that the code, build, run, and debug loop of most statically typed programming languages are a real barrier to productivity. I love C#. I use it in my day job. It also frustrates me because I am locked into the code, build, run, and debug cycle. I just dont work that way. I like the exploratory iterative approach with immediate feedback as a way to design software.
IronPython is free. The source code is also free and both the object and source can be freely distributed in your own application, which is exactly what I am planning to do with my own open source software design tool. Stay tuned.
Monday, July 17, 2006
My blog has been a year long journey of discovery which has led me to a conclusion in the field of software industrialization. This conclusion is now my main pursuit.
Therefore, no more blogging and frankly, after 80 posts on the subject area, I dont have anything more to say, or at least for a while anyway.
The one thing I do have to say is that I wish my blogging software had the blog titles in the Archives list instead of the month/year date labels, including the number of posts beside each month. Given the subject matter, I think this rather ironic. To overcome this, I manually cut n pasted the titles into this post (newest first, in descending order) as a human readable index to the articles.
Tuesday, July 04, 2006
Have you seen the IronPython integration project in the June VSSDK? Aaron Marten and Team have done an outstanding job integrating IronPython into the Visual Studio IDE. I have lived in Visual Studio since 1997, and can say that the IronPython integration is totally pro.
In the VSSDK path C:\Program Files\Visual Studio 2005 SDK\2006.06\VisualStudioIntegration\Samples\IronPythonIntegration you can find the IronPython.sln solution file for the IronPython Project System which features include:
Defines a VSPackage that controls the interaction between Visual Studio and the IronPython compiler.
Participates in building, deployment, and source code control.
Includes MSBuild targets and templates.
Offers debugging support, but no expression evaluator.
Displays and manages project items in the Solution Explorer.
Participates in the Open Project and New Project dialog boxes.
Exposes project and configuration properties, both generic and specific to IronPython, such as the "main" program file.
References web services, databases, and other resources, but not other IronPython assemblies.
Supports automation.
Connects the Windows Form Designer to the IronPython CodeDom.
Press F5 to build the sample, register it in the experimental hive, and start Visual Studio from the experimental hive.
The last statement is interesting. For anyone that has used the pioneering DSL Toolkit knows that running this solution will launch another instance of Visual Studio, and in this case, complete with the integrated IronPython project system now running. If you click on New Project, the following dialog appears:
And sure enough, the PythonPoject is fully integrated into this instance of Visual Studio 2005. It works just like a C# Project Type, for example. In other words it is seamless and consistent within the Visual Studio IDE paradigm. A real testament to Visual Studios pluggable language architecture.
I developed a small IronPython Windows app to try it out. I wanted to see how the Win Forms Designer generated the IronPython code and what it looked like compared to C# Windows Forms apps. So I dragged a ListBox onto the Design surface. Yes, all of the WinForm Designer and toolbox are there. Then in the Form code, I called System.Reflection to get the Types from Mapack.dll and then add the Types to listBox1. Currently there is no support for Partial classes so the Designer code and your Form code are in the same file. One way around this is intelligent use of VS #regions to package code bundles in the same source file.
Btw, the Mapack.dll is an excellent example of the type of reusable Assembly I am talking about with respect to software industrialization. Here is an encapsulated package of Math functions that you can just plug-in to your application. A good abstraction and packaged at the right level in my mind.
My only complaint is that the Mapack.xml code documentation file did not come with the DLL. I wish the VS IDE came with a compile option to include source code documentation in the Assembly. As I have mentioned elsewhere, I think having the source code documentation in a separate external file breaks an encapsulation principle in my opinion. And the first thing to get lost, yes? Plus if I want to program Assemblies instead of source code files, then it would be nice to be able to retrieve the documentation through System.Reflection as it seems you can do everything else with this namespace.
Note the IronPython Visual Studio project is the bottom most Application on the screen. When that is run, another instance of Visual Studio is created with the IronPython project integrated into the running instance. Then I opened up a IronPython windows application project called, Browser1. Running that project launches the small windows app with listBox1 populated with the Mapack.dll Types. You can see the IronPython code in the Browser1 project to the left of the Windows app and on the far right, you can see the 5 projects that make up the IronPython VS integration project.
Another cool integration point is the IronPython interactive console that is directly integrated into the Visual Studio environment on one of the tabs:
The console window is a tool window that creates a TextBuffer object and hosts a TextView control that is initialized to use the text buffer. The interaction between the console window and the IronPython engine is handled by the implementation of the IConsole interface and the definition of the streams used by the engine as standard output and standard error. The history is implemented using a class called HistoryBuffer that stores the list of commands executed inside the console, sorted by execution order. Statement completion and colorization are implemented using the same IronPython language service that is used inside the standard editor when editing a py file. The different behavior of the language service in the editor window and console window is implemented using one functionality exposed by the IronPython language service through its version of the Source class. This object, defined in the MPF, is an abstraction on top of the text buffer and text view.
Wow, when I read that I was expecting a super deluxe console window and it is. Now thats an interactive console window!
As you browse the source files in the PythonProject you will also notice several XML Overview files, Class Diagrams and test suite metrics for each project. Nice.
If you are a Visual Studio code jockey, do yourself a favor and have a look at the Visual Studio IronPython integration project, its as pro as it gets in our software development world. Kudos to Aaron and team!
If you want to tune in to the IronPython world, I would recommend that you visit CodePlex to get IronPython and sign up to the Listserver. Dino and crew are extremely helpful in answering any questions that are posted. The IronPython community is vibrant one with daily action.
Finally, if you are a statically typed programmer feeling a bit shackled by a universe that the compiler creates, unshackle yourself and enter a universe that is still dynamic after compile time. You owe it to yourself to check out the IronPython integration project in the VSSDK.
Monday, June 26, 2006
The .NET Framework Class Library and the common language runtime (CLR) serve as the foundation for all .NET-based applications. But how much do you know about any of the thousands of CLR classes in the library and where do you begin to learn about them?
In this article, the author uses the number of relationships with other types to determine which types are going to affect your programming most frequently and how often you'll encounter them. He programmatically surveys the CLR library using reflection to make that determination. Following that, an in-depth examination of the nine most important CLR types is provided.
I like this article as it shows a pragmatic way of understanding the .NET FCL. In addition, using Lutz Roeders Reflector, you can literally inspect, disassemble and decompile any Assembly, (.NET FCL or other assemblies), to your favorite .NET language. Do you believe that source code = design? Even though the article is 14 years old, it is one of the most decisive articles on software design I have ever seen. It also most closely resembles my belief the source code listings are the design documents.
Since the FCL and runtime (application execution) environment are packaged together, you basically have a programmable runtime environment. Using a dynamic language, like say, IronPython, and through an interactive console, I can program the FCL and have it execute as I am programming line for line. As each line is entered in the IronPython interactive console it is being dynamically executed by the IronPython engine (interpreter). In some lines of code, I have built a trivial Windows Presentation Foundation application borrowed from the tutorial that comes with the IronPython download.
As trivial as it is, there is an important concept being demonstrated here which is with IronPython embedded in your .NET application or in Visual Studio (i.e. using the VSSDK) or using the standalone interactive console, you can dynamically program the execution environment so to speak. A programmable runtime environment.
I have always been a fan of software reuse, mainly because I am lazy. Also, I know it works. I make a living at it. In my world of programming business applications, the reality is that most if not all of it has already been coded several times over. As seasoned programmer once said to me, its all been done before. When was the word processor invented? How many word processors have we had since? Whats different? Probably the same thought goes for spreadsheets, workflow - paper or otherwise, invoicing, ecommerce, etc. Most of these business problems have already been solved with software many (or a million) times over. My question is, how can I reuse this incredible wealth of software that has already been designed and built? Thats my thesis to prove.
I can reuse software much like the way I am practicing today, finding components of various sizes and shapes that loosely or exactly match a functionally decomposed problem I need to solve. For example, my System Browser needed a way to parse an Assemblys XML document file to retrieve code comments on Types and Members when reflecting on an Assembly. Surely that has been written before is what I am thinking. And with a little bit of searching, yes it has, to the point where after I have included the example class (or Assembly) in my System Browser application, I can integrate it with one line of code.
This means I did not have to modify the code at all, I could just use the public interface and problem solved. Next component. And that is how I am building my System Browser application. The 80/20 rule is in effect. 80% reuse and 20% net new code, distributed between coding new functionality, modifications to existing components, and glue code to stitch all of the pieces together.
So what am I saying? I am saying that there is a lot of code out there in the world to reuse. I and others have been doing it for years. Sometimes known in our practice as clip-board inheritance. But, how can I pragmatically reuse pre-built code? While having the source is nice, it does not have to be a requirement. In fact, using System.Reflection will let you look at practically anything inside the Assemblies black box. And I can load any black box (i.e. Assembly, COM Object) and not only inspect it, but use it dynamically in my application using an embedded IronPython engine. Thats what the System Browser is all about. A tool to dynamically program the runtime environment.
The System Browser application is designed to be an emulation of Smalltalks programming environment. It has a dynamic/interpreted programming language integrated with a large class library and an application execution environment. Essentially a virtual machine.
Rather than Smalltalk, and the Smalltalks class library, I am using IronPython and the .NET 2.0 FCL. The CLR on a Windows OS takes care of the application execution environment. Through a similar GUI like Smalltalks System Browser, I can use System.Reflection to get access to the Type system. Using IronPython I can dynamically create new classes and subclass the FCL at will.
Not only can I browse and use in real-time the FCL, I can do that with any other .NET assembly or COM object. I wonder how many .NET assemblies are compiled everyday world-wide? How many COM objects over the years have been compiled? I must have produced over 100 DLLs by now after 15 years at it. I am one of approximately 12 million programmers worldwide. According to IDC, the number of professional developers worldwide will increase to 13.3 million by 2006 from 7.8 million in 2001.
Theoretically speaking, even if each developer compiled the equivalent of 1 DLL a year over the last 10 years, times 10 million developers, thats tens of millions of DLLs that have been produced. Even if it is a magnitude more or less, its still an incredible amount of potentially reusable DLLs. Again, how to use them?
I modeled my System Browser after Smalltalks System Browser. Why? Smalltalk and its environment was best suited for me where I can browse classes, instantiate them, inspect other instances, manipulate them, all in a simple to use dynamic environment. At least for me, that was the pinnacle of an OO development environment, along with Brad Coxs Objective C System Browser. Now I can have the same thing but different. Maybe it is just the way I feel most comfortable navigating and manipulating a FCL.
Another reason for this approach is assisting in the industrialization of software development. I want to program at a higher level of abstraction. To me, that means heavy reuse of pre-designed and pre-built, components is critical to raising this level of programming abstraction. Why write source when the compiled unit is already there?
In the many pages of this blog, you will have read statements like, from a software development point of view, given whatever software application or component you have been tasked to build, chances are that it has already been done before. Look it up on the internet. In fact, this System Browser application is being constructed using this reuse pattern.
Once I have found an existing Assembly or COM component or source code (that will be compiled into an Assembly) that meets 80% (or best choice) of my requirement, I download the assembly and import it into my image or System Browser which means it just became part of the programmable runtime environment.
Now I can reflect on the assembly and all of its Public Types and Members. If there is an associated XML code documentation file, then that is parsed and displayed each time I click on a Type or Member. If there isnt a corresponding document XML file, then I code generate on the fly an XML code documentation file, using a standard template, so that a sentence is formed for each Type and Member as basic (but editable) code documentation. It is already generated and reflected back into the System Browser before you can click on anything.
Using the embedded IronPython inside the System Browser, as I am entering code in the console window (interactive mode) and/or code editor (file mode), both are being recorded then compiled and added to System Browser on the fly. This is done in real-time and totally seamless. At least that is one of the goals of my System Browser.
I would not take too much of this too seriously. This is more of an experiment for me to learn from. It is for my research on software industrialization. However, the System Browser will be freely available just like the IronPython interpreter embedded in it. You will be able to reference assemblies and COM objects, browse their public Types, Members, code documentation to learn from and also be able to dynamically use those Types in your applications. Or at the very least experiment with the Types. I just like programming at a higher level and leveraging perfectly good code that was built before me. Based on my research and own experiences, there sure is a lot of pre-built code out in the world to be reused in your applications, or at least in the business applications I have been tasked to develop at my day job.
This last post was my design rationale or thesis on its applicability to assisting software industrialization by promoting Assembly reuse. A higher level programming abstraction. Something I think our software industry could use.
Wednesday, June 14, 2006
I have made some progress developing a Smalltalk like System Browser for reflecting .NET Types with an IronPython embedded console interpreter to manipulate the reflected Types. Not as much progress as I would like, but with a few hours a week, what can you do.
You can reuse code to increase productivity. Here is something that seems a relatively simple task to do, I want to add an icon (bitmap actually) to each item in my list boxes that represent assemblies, types, properties, methods and events. It turned out not to be so simple as a .NET listbox does not have this capability out of the box. Now what? As I have suggested in the past, the WWW is an excellent (unstructured) catalog of reusable software. I make the assumption that each one of the components I am looking for to build this application has already been built by someone.
Searching away brought up several specialized listbox implementations, but this one I liked the best is called. . NET Color Listbox. Alex has done a great job here as his implementation provided not only the ability to add the bitmaps to each item in the listbox, but also uses DoubleBuffering to get rid of the flickers when scrolling looks nice and smooth.
Where to get the bitmaps that represents assemblies, classes, methods, etc.? If you have Visual Studio 2005 installed, you will find them at: C:\Program Files\Microsoft Visual Studio 8\Common7\VS2005ImageLibrary as VS2005ImageLibrary.zip. So far so good, no reinventing the wheel yet.
While I still have more work to do on the System Browser part in the way of trimming namespaces in the listboxes, hiding properties that have public assessors, making the constructor bitmap different than the method bitmap, etc., I am going to move onto code comments.
However, it turns out that the C# comments you put in your source files never gets compiled into the assembly. I thought maybe the XML document was an embedded resource as indicated by this example of, Working with Embedded Data :
Using System.Windows.Forms as myAssembly
string[] names = myAssembly.GetManifestResourceNames();
foreach(string name in names)
{
Console.WriteLine(name);
}
Nothing in there other than bitmaps, icons and cursors. While you can embed the XML document as a resource, it is not done at compile time nor included in the .NET FCL.
I am a bit surprised by this. Having the assembly and the documentation for the assembly in two separate files violates the principle of encapsulation in my mind. The first thing to get lost when moving an assembly around is the XML documentation file.
I wonder why two separate files? Yes, I know that the XML doc is also used for IntelliSense comments, but what if it was in the assembly and you reflected on it from the assembly? Is it a size issue? Looking in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 I see that the largest XML file is mscorlib.xml at approximately 7 meg in size whereas the actual mscorlib.dll is just over 4 megs in size. However, the majority of other XML files are in the 100Kbyte range. So maybe memory could be an issue, but at the very least, I would like to have the option of embedding my comments in the DLL so that if other people are reflecting on my Class library, they can also read the comments.
Ok, well, I can still read the comments from the XML document files and load them into the System Browser. Sounds like more code reuse as I am sure someone has written this before. And as it turns out, yes in a couple of ways. One is " XML Comments" which loads the XML documentation based on what you are reflecting on. I have this implemented in the System Browser with one line of code. The other code sample is called, Documenting .NET Assemblies which generates code comments directly from an assembly, even if there is no source comment XML dcoumentation. Looks promising.
I know this post does not have much to do with IronPython (yet), but is the setup for embedding the IronPython interactive console interpreter into the System Browser. The point about using IronPython to dynamically build apps from the .Net FCL and other assemblies requires a System Browser so that we can inspect the Types, grok the meaning and start dynamically building apps all from the same window.
Tuesday, June 06, 2006
A couple of weeks ago I suggested a way of dynamic programming with IronPython. Essentially it is a combination of using a Smalltalk like System Browser to browse types using .NET reflection and embedding an IronPython interactive interpreter into the System Browser to manipulate the reflected types.
Why would I want to do this? While I really like Visual Studio, which I use for my day job, sometimes it takes forever to build a simple prototype or experiment with a new class library. For me, I want to see an app up and running as soon as possible, but at the same time leveraging class libraries and third party components. And I want to do this dynamically.
I am also one of those people that learn best by doing. While I can read the framework class library documentation till I fall asleep, (.NET 2.0 has 29,000 types in it!), I like to play with the types live and through some experimentation, find out how they work. Sure I can use Visual Studios Object Browser or Lutzs Reflector (even as an add-in to VS), but it is not suited for how I work.
Maybe I am old school, but I like the Smalltalk System Browser approach to software development. In .NET it is a little harder because the Smalltalk world was really simple, you had classes, instances and methods. Thats it. In .NET it is more complicated, but still what I am interested is inspecting an assembly for its types and for each type, what are its public properties, methods and events in other words I am using the System Browser as a way to work with the types, not just browse them. Having an IronPython console window embedded in the System Browser lets me play with those types dynamically. To me it is the best of both worlds, leveraging pre-built types to dynamically build my prototype or application.
As a side note, this blogs focus is on software industrialization. I have explained what that means in other posts, but one aspect of software industrialization I would like to point out is simplicity. The ability to browse libraries using the Smalltalk System Browser paradigm and then use those libraries interactively in the same window is simple.
The System Browser is initially built as a C# application, just to get parts of the code design down of what I want and in a language I already know. I am also mirroring the development of the application as a Python Windows application, which is what the final product will be. While I have run into a few problems, mostly my own, I have had excellent support from the folks at the IronPython forum. Of course, I have already made a fool of myself on the forum by repeatedly submitting a chunk of Python code that had a (read: my) mistake in it, which I missed on a couple of occasions. Maybe if I slow down a bit, I will see it before I submit it  Thanks to Dino, Vagmi and J. M. for being patient.
I should also point out that for Windows Forms programmers looking to get a tutorial on creating Windows Forms dynamically using IronPython, should look at Michael Foords excellent tutorials.
Back to the System Browser - maybe I will have something implemented in a couple of weeks or months. Stay tuned.
Saturday, May 27, 2006
As I mentioned in a previous post, I am really excited about IronPython on the .NET platform. The main reason is being able to program dynamically. What I mean is that I can import .NET classes and start using them interactively with the interpreter.
For example, I can interactively build a simple WPF (formerly Avalon) application in just a half dozen lines of code. I dont mean running a script either; I mean entering in one line at a time and immediately seeing the results on the screen.
For example, the following code imports the WPF library (and a small script to allow interactivity between the interpreter and application being constructed), creates a new window instance, displays the window, sets the title and some text in the form, sizes the text and finally sizes the form to the text.
from avalon import *
w = Window()
w.Show()
w.Title = Simple WPF App
w.Content = TextBlock()
w.Content.Text = Aloha IronPython!
w.Content.FontSize = 50
w.SizeToContent = SizeToContent.WidthAndHeight
Alright you say, no big deal. Well, on one hand you are right on the other, I think the point is that it satisfies a major requirement that I have as a programmer which is to interact with building my application in real time. This goes beyond just the compile, link, deploy cycle of compiled languages. This allows me to see what I am doing as I am doing it. Some would say this is hacking with no design documentation and just winging it. Others would use the analogy of a painter and the canvas where you are seeing tangible results in real-time as you are painting just like in the real world and not in our make belief software world. Or even if I had a design document and was following Agile methods, this to me gives immediate verifiable results as you are seeing it on the screen, again in real-time. This whole notion of dynamic programming and the semantic meaning I have for it will be a future topic.
I could take the sample above much further and in fact, if you download IronPython you can follow the tutorial which this snippet is from, plus load up XAML, build event handlers and hook them all up to produce a real working live application with a handful more lines of code. As tutorial states, IronPython provides a very easy way to develop live application in a dynamic and exploratory way. That is what has me very excited about this dynamic programming language on the .NET platform.
.NET 2.0 Framework Class Library has roughly 29,000 types in it. Plus, as I have written elsewhere in this site on software industrialization, there are tens of thousands more COM dlls and other .NET dlls that have been written. My point is that though IronPython any of these types can be imported and used dynamically in any application you may be building, particularly if you are predisposed to performing programming in a dynamic and exploratory way.
How to so this? In my post on Software Industrialization using .NET Reflector and IronPython, I suggested building a Smalltalk like System Browser with and IronPython interpreter built into it. While Lutz Roeders .NET Reflector product is excellent and highly recommended, for me, it is difficult to use from a tree view perspective. I much prefer Smalltalks System Browser approach plus I can work with types in fewer mouse clicks. Finally, I can embed the IronPython interpreter in the code window so I can work with the types that I am exploring and later as we will see, add my own types on the fly that are subclasses or extensions or glue code to all of the other types that I have loaded.
First things first. How do I get type information? There are several excellent articles on .NET Reflection and the best one summarizes it here. The first thing is to write a wee bit of IronPython code to find the types in any given assembly. Here we are going to get the types out of mapack.dll
IronPython 1.0.2280
Copyright (c) Microsoft Corporation. All rights reserved.
>>> from System.Reflection import *
>>> a = Assembly.LoadFrom("mapack.dll")
>>> Types = a.GetTypes()
>>> for Type in Types:
... print Type
...
Mapack.CholeskyDecomposition
Mapack.EigenvalueDecomposition
Mapack.LuDecomposition
Mapack.Matrix
Mapack.QrDecomposition
Mapack.SingularValueDecomposition
>>>
Easy enough. Next post in this series is to build a Windows App (in IronPython of course) that starts to take on the shape of a Smalltalk System Browser so we can start reflecting types for possible inclusion for the apps we are building.
Friday, May 26, 2006
I remember in the mid 90s when software reuse was a big deal. Several books came out that discussed the need for software reuse and how to set up a reuse library in your organization. My favorite is, Confessions of a Used Program Salesman: Institutionalizing Software Reuse, by Will Tracz. One of the very few textbooks I have read that was as entertaining as it was useful.
10 years later I dont see much about software reuse at all. I dont find it as a topic of discussion on any programming related forums. Is it because we as computer scientists, software engineers, or programmers have institutionalized it as standard operating procedure or is it because the fascination we have over programming languages, software reuse is a forgotten practice?
Looking up software reuse on Wikiepedia gets redirected to code reuse. This was a real surprise to me. I use Wikipedia quite a bit for software related information and it is usually is up to date and accurate. However, to equate software reuse with code reuse is missing the point of software reuse in general. I would define software reuse as the ability to leverage any existing software artifact that makes solving any software problem easier. Whether it is a project management schedule template to a fully blown domain specific language for automatically generating ecommerce solutions would be considered software reuse in my book.
I know there are several libraries, SDKs, commercial components, etc., that come with your favorite programming language. Even K&R C from 1978 had this and probably even earlier before my time entering the computing world. The mid 90s also had the explosion of design patterns, the Gang of Four being the most familiar to software designers and programmers. Today there is an incredible wealth of design patterns. I am wondering if we ever use them? I must admit that while I have used some design patterns in a few projects and probably some unknowingly, I dont go out of my way to decompose my software designs into patterns, cause quite frankly, in my world of professional software development services, we never have time for such activities. My software development world is governed by the clock get it done as soon as possible.
So how do we implement reuse in our organization? In a nutshell, we Google it. Here is how it works. Our customer needs a custom web application built with certain functionality (what that functionality is does not really matter, because it has usually been done before). Our projects typically take on two distinct phases. Phase 1 is to write up a requirements specification, usually in the form of use cases and storyboards, all of which we have a library of templates which we reuse, including the statement of work, project schedules, etc. The customer signs-off and we are on to Phase 2.
Phase 2 begins with, what do we have from a previous project that we can reuse? That means any ASP.NET web pages, controls, components, custom assemblies that we have written before that we can leverage. For the pieces we dont have, we start our search with Google and other tools, looking in the usual suspect places where we know we can find example/sample designs and code that we can reuse in our overall solution. Since we are a Microsoft shop specializing in custom ASP.NET, SharePoint and just plain .NET applications, we know where to look. In fact, we have several links in our SharePoint library that points to our regular spots.
Once we have gathered all of the pieces, we look at what actual custom code is left to do. Surprisingly (or not) not much is left to do other than glue the pieces together and apply the paint. Now I make it sound easier than it is, but I would say on average that well over 50% of any custom development work we do is reusing pieces (on top of the .NET Framework Class Library) and in some cases as high as 80% software reuse. Just to be clear, we are a .NET shop only and we are not implementing or deploying packaged products, except in the case of SharePoint and then we only get involved in custom development using the APIs and/or page layout.
We have our test harnesses for unit testing, system testing, FxCop design and code coverage tests, performance and stress testing, bug tracking templates, etc. These are also reusable tool and template assets that we have accumulated and customized over the years. Some of the custom applications we have designed and developed handle over 1 million transactions per day that I think are good pieces of work. And others, well, you know, right? Since we have yet to reach a stage of industrialization in our software world, some projects are better than others.
So when does software reuse not work well? In our case it is the adoption of new technologies such as Microsofts SharePoint 2007 which just reached Beta 2. The problem here is that the architecture is so new that very little in the way of samples, examples or how tos has been developed. Here we are on our own, with little documentation, massively changed APIs and of course a Beta product.
What does this have to do with asking the question if we as the software community are reusing software? I guess thats the point. We seem to be doing it but when we are hiring new candidates (including seasoned professionals) only a few of them can point to reusing software and it usually is code reuse and even fewer have experience with design patterns. I cant believe we are the only ones doing it. But the friends I have in other software organizations also point to a very small percentage of software reuse in their own orgs. Why is that?
I dont think I have the answer to that question. I see that there is an international conference on software reuse this year. Not sure who attends these. I wish I could go to Italy Spending more time on Google does not help as most of the links to the subject matter in question are relatively old. It seems no longer a hot topic.
I would be interested to hear other peoples stories of software reuse. If you have a moment and would like to share, let me know. Thanks.
© Copyright 2008 Mitch Barnett - Software Industrialization is the computerization of software design and function.
newtelligence dasBlog 1.9.6264.0 Theme design by Bryan Bell  | Page rendered at Tuesday, November 18, 2008 8:06:43 PM (Pacific Standard Time, UTC-08:00)
|
|