Tuesday, September 15, 2009

Lack of Discipline or Inappropriate Deployment ?

Speaking with a fellow consultant at the Real World DITA Conference, there was some talk that the content management profession was unfocused, that the industry was expending too much effort doing the same things in so many different ways that reuse of strategies is hindered. One thought posited was that people needed to focus effort on standardized methods, which seemed to be premised on the idea that the diversity of practice was a bad thing in and of itself.

It may be. As a programmer dealing with ever shifting platforms and ever expanding universe of "standards", I sympathize with the sense of frustration. We do spend way too much time on retooling, and too little time getting use out of the tools. Perhaps open source is to partially to blame here, as it has cheapened the perceived value of the tool chains. That cannot explain why professionals don't practice their trade uniformly.

But it isn't just a matter of diversity of practice, it is also, more fundamentally, a matter of deploying layers of IT infrastructure with inappropriate technology. Object-oriented MVC Java and .NET technologies are the main culprits here, in so far as these technologies have served to mask and increase complexity, rather than actively reduce it.

The insistence on compartmentalizing the handling of data through physical call-return control flows contributes to complexity. Frameworks like Spring introduce inversion of control in an attempt to mitigate issues in software construction and platform integration processes. But doesn't the need for such dynamic API mappings suggest that the underlying architectural layering assumptions were wrong to begin with? I'm not arguing that Spring, MVC, or inversion control are bad, but that other approaches to integrating applications may bypass the need for direct interactions between components, and thus eliminate some of the complexities introduced by over reliance on these low-level mechanism.

Scripted extensibility interfaces, IMHO, are too little appreciated in the industry in comparison with the twin bastard "platform" technologies Java and .NET . I have worked with proprietary client-server application platforms which provided far greater levels of productivity. One way they did this was by limiting their scope of application to database client-server GUIs -- a fair criticism.

Another observation though, is that many of these 4GL environments did a good job of closing the loop for building an application, and of providing straightforward, concrete patterns of practice to achieve useful application behavior. And the applications were maintainable. We could make them work and put them into production for years. Today's browser/server environments are certainly richer and provide a more robust vocabulary, but they are also much less stable and don't last for what -- months -- in practice?

I leave this post with a phrase, with little further explanation: Invasive Programming by Side Effects. We need to build pipelines.

No comments: