Eric Newcomer's Blog

Since I wrote this article questioning the validity of the Henry Ford analogy for improving software productivity through interface standardization, there's been some good posts by Hal Hildebrand and Richard Nicholson, and some good feedback at SYS-CON.com too.

While I have to say I think the posts and comments make excellent points about the value of design, and the differences between mass producing hard goods and creating individual applications, I am not sure any clear recommendation is emerging for how to improve the software development process. So now I am wondering whether we can get at this progblem through patterns.

One aspect of the debate over software productivity and assembly is whether or not visual tools can help. I think that they do - visual abstractions can be very meaningful - but I do not know of any visual system that actually solves the complete problem (i.e none have solved the customization/round trip problem). UML tools are furthermore too object oriented for some applications - such as services and REST- although of course I will get an argument from the UML (and MDA?) folks that models are the way to go anyway, and UML and MDA are being changed to be more data and document oriented (i.e. sequence diagrams could be improved in this direction).

I admit I am not up to date with the latest in UML and MDA. But I also don't know of any reason to change my view that they do not provide the answer. I have yet to see any graphical system entirely able to replace any human oriented language, and I do not think programming languages are any different. People still need text, even when the graphics and icons are superb.

So noting the growing adoption of software patterns, including integration patterns and SOA patterns, and observing the fact that software systems such as Apache Camel for example, are starting to be built around them, I can't help wondering whether the solution might be found there.

The fundamental issue seems to be identifying the right abstractions. Software is the way people have of telling computers what to do, and it is still too hard, requiring way too much work.

In the Henry Ford analogy, the API (or interface) is seen as the right abstraction. As long as the interface to a program is standardized, its implementation can contain any code. With a standardized interface, programs can be assembled with predictable results (i.e. other programs know what to expect when invoking the interface). This led to the idea of reuse, of libraries of components, objects, and services that someone could sell and others could use in building applications. And this has happened to some extent, but there are also many unfulfilled promises in this area (as David Chappell, among others, has pointed out).

Now if we look at patterns, and how Camel is representing them in software, we see a different type of abstraction being used - basically a variation on the theme of domain specific languages. The domain in this case being integration, and the realization of integration patterns in particular.

One of the challenges of DSLs is integration in fact - that is, how do you join together programs written using different DSLs into a system or application? It sounds like a crazy idea, but what if we were to use integration techniques, such as patterns, themseleves implemented using DSLs, to join programs together written using other DSLs?

Would we have the abstractions right? I.e. in the language instead of in pictures or interfaces? And would we be able to assemble programs together quickly and easily? Maybe we need some patterns specifically for application assembly?