Pragmatic Dictator

That is the front page headline of The Sun newspaper with similar wording in The Mirror and in some of the local rags handed out around London. These headlines are of course related to the horrible business over at Virginia Tech and sadly, I believe they are making a bad situation worse.

These kinds of headlines demonize the attack and ultimately place the blame squarely on the gunman. Demonization has historically been used as a powerful tool for motivating armies to fight, just think about how a lot of people have described Iraqi forces or the Nazis. Fortunately the likes of Tim Collins have stood up and said this is not the right way and done something about it (meeting significant political resistance along the way).

So if the military have figured out that demonization is not a good tactic, why do we as a society allow this to be pushed through our newspapers and other channels? Perhaps because it allows us to blame someone else and move on? Make no mistake the incident at Virginia Tech is appalling but if we are to learn lessons we need to avoid blaming the gunman and start asking ourselves as a society some harsh questions like “why did we ignore the warning signs?”

Technorati Tags: Virginia Tech

There’s been a lot of chatter recently in the blogosphere about the technical direction of the database. This discussion has been ongoing for some time and dates back to at least Bosworth’s utterings.

It kind of reminds me of the old “we’ll never use that much memory” argument, “you’ll never need more than one database”. I wonder, have we got to the point where most decent size systems be they web or enterprise will need to store more data than can be held in a single database?

Perhaps partitioning and use of dumber storage mechanisms¹ will become the norm? It strikes me that this might be a more promising approach² than attempting to build clusters when working with utility compute platforms like EC2/S3. Seems like we have some design patterns appearing, just need the frameworks to catch up?

[1] Might include RDBMS used purely for storage, containing no business logic.

[2] Partitioning might provide simpler and cheaper growth strategies than the aggravation of upgrading the server hardware for the database

Technorati Tags: architecture, storage

One evening an old Cherokee told his grandson about a battle that goes on inside people. He said, “My son, the battle is between two wolves inside us all..

One is Evil. It is anger, envy, jealousy, sorrow, regret, greed, arrogance, self-pity, guilt, resentment, inferiority, lies, false pride, superiority, and ego.

The other is Good. It is joy, peace, love, hope, serenity, humility, kindness, benevolence,empathy, generosity, truth, compassion and faith.”

The grand son thought about it for a minute and then asked his grandfather: “Which wolf wins?”

The old Cherokee simply replied, “The one you feed.”

[With thanks to Dave Zaffery for pointing me at this]

Technorati Tags: personal, philosophy

A transaction is an abstraction that provides some combination of the ACID properties.

This is just a concept. The trouble is we’ve created implementations of the concept that carry the same name. The result has been that we’ve forgotten about the concept and associate the term “transaction” typically with the RDBMS implementation of the concept.

This confusion can have significant impact when we get to design of a transactional system. What you really want to build is a system which provides the appropriate balance of ACID properties but what you usually end up doing is constructing your system around a database – i.e. we dumped design and went straight to a common implementation with no consideration for what we really set out to achieve.

And in a twist of irony, I was going to link to the ACID page over at Wikipedia but it makes the very mistake I’m blogging about! So instead I’ll point to Page 3 of Transaction Processing: Concepts and Techniques by Gray and Reuter.

Technorati Tags: architecture, design, distributed systems

It’s an all too familiar story, an overflowing inbox of rapid fire emails day after day. A ceaseless bombardment of meeting requests, news updates, design discussions, status reports, the list goes on. It doesn’t take long for this bombardment to push recipients into pavlovian responses such as:

1. If the subject doesn’t have immediate meaning, delete the email
2. Another status email which surely is like all the previous ones, delete it
3. Another request to a meeting – book it into the calendar without a second’s thought

These behaviours and others are quite damaging to your organization. Potentially useful information is ignored, people end up permanently in meetings, never getting anything done or pausing to think strategically.

So what’s the problem? To echo a previous post, email is a push mechanism and worse, it tends to be an interrupting push mechanism. We are all familiar with bouncing icons or fading dialogues displaying recipient, subject etc of a just-received email. Email can also be problematic to manage:

1. Mailing lists are difficult to keep up to date
2. Getting on and off mailing lists can often be more complex than is desirable
3. How do you find the right people to email to?

So what might we use instead? How about blogs and RSS feeds? Blogs are a fine place to publish announcements, news, status reports etc. We have a wide range of readers, online and offline and managing subscriptions is a key area of focus for these applications. RSS of course gives us a pull mechanism allowing subscribers to choose how often they receive the updates. All that’s left is to maintain a well known page to link the blogs (and you can regularly email a link to that page around) so that potentially interested readers can find the subject matter they require.

It all seems so obvious and yet there are still a mound of corporates out there that haven’t moved to this more balanced approach to information dissemination and co-ordination.

Technorati Tags: management, process