Pragmatic Dictator

The “what is a JavaSpace debate” rages on………….

Fundamentally, I don’t see this as being an exercise in pragmatists vs purists. It’s a difference in engineering philosophy/taste. Personally, I see a JavaSpace as well, errr, a JavaSpace. There are lots of things you can do with it:

• Co-ordination mechanisms
• Systems of co-operating entities for e.g. locking, queues etc
• Compute Servers
• Messaging
• Caching

Note that all of these things can be built on top of JavaSpaces. This leads to two different schools of thought:

1. Make all these different things a part of a JavaSpaces implementation
2. Make all these things layered frameworks that live on top of JavaSpaces

Arguments for the first option are often on the basis of improving performance or “making JavaSpaces more useful”. But JavaSpaces is already useful, acting as good simple underpinnings for all these different things.

And this is why I personally prefer the second option. I’m a minimalist, I like my JavaSpaces nice and simple and I like being able to construct cleanly layered frameworks on top of JavaSpaces. This allows me to have nicely separated responsibilities at each layer leading to (IMHO) better, more understandable, more maintainable design in my systems. I also like to avoid building such layers on top of JavaSpaces if there’s something out there already that can do the job better in a specific scenario.

[ Yep, read that paragraph again and realize that I am both pragmatist and purist. How annoying that I cannot be easily pigeon-holed as one or the other! ]

There’s no accounting for taste but let’s be clear that it has nothing to do with being pragmatic or purist. It seems like Cameron also has a taste for minimalism……

Technorati Tags: design, engineering, philosophy

Hot news is the proposal for a REST API in Java. Equally interesting is that various members of the community are asking for a simple API with none of the usual cruft.

I’m left wondering if such an approach will just leave you with all the existing http libraries and web infrastructure (servers, caches and proxies) such as Apache’s HttpClient.

It might be that the real core of doing better REST is in tools for converting from REST-based designs into code and infrastructure rather than an API per se. Could be time to go look at what DHH and Rails have been doing in this area???

Technorati Tags: design, REST, Rails

This is interesting:

“W3C members have issues surrounding enterprise computing. Not just distributed computing, but the typical concerns around transactions, scalability, high availability, and so on. Not only that they’re also dealing with 15, 20, and 25 year old technology that works just fine but is getting more and more difficult to maintain and doesn’t play well with others. Finally, there’s the issue of interconnecting these systems to each other, to partners, and to the Web.”

Once 15+ year old technology is getting difficult to maintain and doesn’t play nice with others, surely it’s time to considering throwing it out? Surely keeping it just forces all the new stuff we do to get bogged down and stifled supporting the old stuff?

I’m just wondering if the logical destination for this will be we can’t make progress any more because we get completely bogged down in our legacy? I certainly appreciate the companies holding on to so much legacy consider it important that the issue is tackled but should the rest of the world which is perhaps more flexible have to care? Should we constantly be bending all the good new stuff we do to cope with all this old crud?

If you buy a car there’s a limit to it’s useful life. You can keep running it after that but maintenance bills get higher and higher to the point where one gives up and just buys a new car because it’s cheaper.

Note also that the owner of this “legacy” car is the one suffering the high maintenance cost, not the manufacturer or the mechanic. Admittedly, the mechanic and the manufacturer must hold onto tools and parts but they can at a point of their choosing drop support. Should it not also be the case that companies holding onto legacy systems suffer similar high maintenance costs? Should these companies be able to displace those costs onto others in the form of horrendous complexity and endless legacy considerations in new products, specs etc?

Clearly there is no right answer for this dilemma but it might be time for us all to sit down and consider the whole cost of holding onto legacy which goes way beyond the simple increasing cost of maintenance.

If nothing else it strikes me as interesting that whilst IT pursues the concept of endless life for systems, nature provides many examples of limited lifespan as a useful tool for progress and sustainability.

Technorati Tags: enterprise, technology