Ralf's Sudelbücher

Have you ever pondered the current practice of referencing assemblies from within a VS.NET project? I haven´t much until recently. I just took this way of linking to code for granted. It´s how we do dynamic linking today. Great!

Or isn´t it?

No, I don´t think it´s that great. I think it limits our thinking on how we develop software. It is just one way to link components together at runtime.

What´s limiting in referencing assemblies is that it binds the component under development to a certain implementation of other components. Isn´t that, what we want, you might ask? Yes, sure, that´s what we need and want for components that already exist (lets call them libraries) while we develop our own component.

When I work on my component, I need the services of libraries like the .NET Fx DLLs or the assembly of my favorite DataGrid. Those libraries exist prior to my project, their interfaces are set, their implementation is complete. So, sure, I should be able to include their services into my component by setting a reference to them, thereby importing not only their meta data, but also later on during runtim loading concrete assemblies.

But when I want to do real component based development (CBD), then I consequentially want to divide my own application up into several modules/components. These components will be developed by several programmers in parallel. This will often lead to situations where a developer working on component A needs component B - which is still under development. But this scenario is not well supported by VS.NET or the .NET Fx.

I cannot reference an assembly that does not exist yet. So what should I do in my project? There are several ways out of this dilemma. The one chosen most often is not to develop components at all. Next comes building huge solutions with many, many projects in them. Both ways sooner or later lead to tight coupling between components and thus thwart the vision of CBD.

But there is a third way: I could define interfaces for components first and put them in a separate assembly. This assembly I could readly reference in my component A project. I´d then know how to use component B thru its interface IB. Great!

Or isn´t it?

Yes, a very good idea - but no well supported by VS.NET and the .NET Fx. Because this way entails you need to discover the implementation of the interfaces you bind to during runtime. Currently there is no way to accomplish that. You can´t pass an interface type to Activator.CreateInstance() and ask it to instanciate an unknown class implementing that interface.

But that´s what´s necessary if you truely want to decouple a client component A from the implementation of some interface IB. Because during development of A you might use mock-up component BMockup which implements IB. But later on a client´s system BMockup has to be replaced by BFinal. Or maybe you want to try different implementations of IB, e.g. BStrategy1 and BStrategy2. How do you bind to those different implementations during development? Not at all, because they don´t exist.

That´s what I mean, when I state, VS.NET contrains the development process. VS.NET and the .NET Fx are targeted towards developing applications where all implementations are well known during development time. It supports well bottom-up development. But it does not support well parallel, independet development. We still need to come up with additional infrastructure to overcome these limitations. We need to build our own Contract First tools for intra application interfaces between components.

I have to admit, yesterday´s posting on Microsoft´s olfactoric tool Code Smell Cop (CSCop) was an April Fools Day joke. But still... I´d like to see tool support for more than our eye and ear senses. What about tactile feedback while programming, e.g. depending on amount of code in a method or class or assembly?

According to the German .NET developer magazine dotnetpro, Microsoft has shown a prototype of its new CSCop refactoring tool at CeBit 2005 (read full article here (in German)).

CSCop stands for Code Smell Cop and is developed by Microsoft Research. CSCop analyses .NET code (C#, VB.NET, and also IL) and - based on modern AI technologies like Bayesian networks - assesses if it needs refactoring.

This alone is already revolutionary since Kent Beck and Martin Fowler in Fowler`s book "Refactoring" stated, they could not give any hard criteria to determine the "unstructuredness" of code.

But Microsoft has not only solved this problem through merciless analysis of its own code base. In addition to this, Microsoft developed a completely new olfactoric user interface! CSCop flags code which needs refactoring by producing smells.

Kent Beck coined the term "code smell" and Microsoft took this to heart to develop a user interface orthogonal to the common visual GUI. When viewing "bad code" in VS.NET 2005 with the CSCop stick attached to the USB port, the developer will soon smell a unique stench characterizing the kind of "misstructure" he´s looking at.

According to Microsoft´s Steve Eson (lead developer of CSCop) it was quite difficult to find a set of "base smells" to mix all the necessary nuances of code smell from. Another challenge was to find a way to make the smells not too "sticky" but nonetheless be able to provide a characteristic smell for a whole application. CSCop currently is in beta 1.

We´ll see, if developers will embrace a tool which makes code structure quality so obvious to anybody entering their cubicles.

In my previous postings I talked about two perceptions: 1. I don´t see any real signs that make our trade of software development singular and hard to compare to other industries. 2. The rate of change in our industry has increased very much in the past 10 to 20 years and makes it impossible to keep up our attitude of allround programmers.

Ok, so now that any “attitude” is out of our way (see my previous posting for details), we can start to look at what is the real challenge for programmers today.

Let me start my reasoning about how the people-side of the future of software development might look like with two perceptions that form the basis of my argumentation.

Motivated by I a conversation with Steve Cook, one of the fathers of the Software Factory concept ([1], [2]), I´d like to share some thoughts with you about the future of software development. However, contrary to what you might be thinking now, I don´t want to speculate much about the next versions of the .NET Framework or how virtual shared memory could help to solve interop problems or the benefits of Intentional Programming.

Are you looking for information on how it feels like, when you use an O/R Mapping tool in your .NET applications in general? How - if at all? - does the programming model change? What is it like to live without DataAdapters and DataSets?