Pragmatic Dictator

That’s right I’m stupid, I must be cos I learn something new and significant every day.

And I’m not talking about some API detail or some new framework I mean I’m changing my thinking, I’m changing me, I’m seeing a bigger picture. I want topsight^[1], not nitty gritty detail. Detail is easy to cope with if you can see the higher view, how things fit and interact.

If I were clever, there’d be nothing more to learn and I’d have answers to all questions. Knowledge is all very fine but it comes through learning and that comes through experiencing things and that’s what makes you smarter. Having a big brain isn’t enough.

[1] Topsight – a term used by Gelernter in MirrorWorlds, meaning the ability to view the whole system rather than small details.

How many times does something like this have to happen before we understand that:

1. Business isn’t about ethics.
2. Many a lawyer feeds off point (1).
3. The cost of (1) and (2) is a human cost.

And when will we all stand up, demand a change and make sure something is done about it? Next time your tax bill rises or you get bad service from a company who will you blame? Business or yourself for silently putting up with it?

Technorati Tags: philosophy, business, society

Dare has this to say about API versioning. His basic approach can be summarized as don’t change anything at all and separate your URL space using some version moniker. This is a good piece of advice but I’m more wary of other aspects of the posting such as the suggestion that we should support all versions over time to maintain backward compatibility.

I’m tempted to suggest that this is a classic Microsoft (and enterprise) mindset: pile up a stack of legacy and backward compatibility requirement which can potentially lead to a mess of complexity and brittleness underneath the APIs. I feel the reasoning around client migration also needs re-examination. This is because Live Messenger doesn’t live in a browser. It is a desktop native binary application and therefore has completely different characteristics from a genuine web application in terms of dispersal, upgrading and updates.

Consider that for many a browser based application, upgrades are but a reload away. Further many a web service that is mashed up as part of another offering will ultimately present to a user as a browser-based UI. i.e. We don’t need all our desktops to upgrade, we need to upgrade the integration point in the backend services of the mashups that use the web service. That’s at least potentially considerably fewer entities that need to upgrade than is normal in the desktop world.

Dare’s posting also seems to have an underlying current of belief that one can define an API perfectly in the first place. We have known for a long time that such a feat of prediction is often very difficult though it can be made more manageable via functional partitioning.

Limited lifetime is one of the best antidotes we have to the complexity of legacy and the brittleness of code. We resist it far too often leading to the mess we have in many an enterprise:

1. Instability
2. Slower Feature Delivery
3. Difficult maintenance

The web, the human body and many real-world systems (cars for example) exploit the concept of limited lifetime successfully, perhaps this philosophy should be more widely applied in software?

Technorati Tags: architecture, browser, enterprise, evolution, versioning, web

Patrick and Fuzzy jumped on something from Mark Baker about Apollo and whether or not it’s built on top of the web.

Mark’s argument essentially amounts to “make it work in the existing browser” as opposed to “extend beyond the browser”. There’s a fine dividing line here because the current environment provided by the browser is limited.

There are a multitude of ways to deal with the fact that browsers don’t support local file access etc. One might be to properly “web-enable” the local computer’s operating system having it provide access to resources etc via 127.0.0.1 in a browser friendly fashion.

Another would be something like Apollo or Java or …..

More interesting for me is that whilst the web is supposed to be this de-centralized thing (and it is indeed in terms of services and combining them together) we’re not really de-centralizing the implementation of individual services such that we are able to push substantial logic into the client-side.

The current model, as I’ve said before, can make maintenance of services easier because new code for the browser is but a page refresh away. I think we could maintain a good deal of this constraint whilst getting closer to something like Apollo.

[ And how Jini like is the web-deployment model? Seems very similar - push the impl to the client just when it needs it. ]

So maybe Apollo isn’t the solution, maybe the existing browser isn’t the solution, maybe we need to consider the browser to be a work in progress, in need of extension so we can build better “on top of the web”.

Who knows?

Why do we want this kind of logic in the client anyway? Well because whilst statelessness is great and all, the reality is that if the state is not held inside of a human being’s head, it’s going to be in the browser and manipulating that state in efficient fashions (not pushing it all back to the server in every call) dictates a fair amount of client-side intelligence. We might also want to batch things up and so on for the purposes of making better use of the network. Lastly we might want enhanced user-interaction but eye-candy is sweet, you can never get enough and your browser could end up obese.

[For more on state in web apps, see Dave Orchard's note]

Technorati Tags: architecture, browser, distributed systems, web

Leave cement lying still for too long and it sets. Once it sets, making adjustments becomes exceedingly difficult. You’ll need pneumatic drills to break it down and bulldozers to remove it. Then you’ll need to bring in a whole new batch to be re-cast in accordance with your wishes.

So it is that software left unstirred for too long becomes brittle and will demand wholesale replacement. One can build a certain amount on such a foundation but eventually it will need a complete reconstruction affecting everything built atop. In this world stirring is refactoring.

Cement has other properties that determine just how quickly it sets and it is the same for software, in the form of do’s and dont’s like loose coupling and separation of concerns. It’s fascinating to note that we spend a massive amount of time focusing on making software malleable at compile/build time (Spring anyone?) but considerably less effort on ensuring similar flexibility post deployment making for brittleness in face of failure, upgrade, configuration changes, scaling etc.

Some aspects of this analogy (not sure what the equivalent of stirring would be) can also be applied to organizational behaviours. For example if one focuses a business heavily on tactical operation for an extended period of time, adapting to more strategic operations will be impeded by it’s structure, modus operandi and culture. Necessary changes might including hiring, firing, reorganization (with significant impact on existing hierarchy), process revision etc.

Technorati Tags: architecture, software

[Blame the child in me for the gratuitous photo's of construction tools ]