Sarbanes-Oxley

The organization, I am currently consulting for, is in the heat of trying to comply with Sarbanes-Oxley. I hear this name mentioned at least twice a week, if not more, as a reason for a number of wrong and potentially dangerous decisions. The act, through legal wording, goes through great detail to specify how auditing shall be done, how its paid for, who is going to do it, what the deliverable will be, etc... The report explicitly assumes that auditing is a major fix to all the accounting problems we are having. As long as the auditors do their job, everything will be fine. The report also touches upon record keeping, and briefly mentions, I believe in one sentence, the requirement to maintain safe access to a production system.
It is very import to question what auditors say. Some of my friends are these auditors; they are overworked, just out of college, being promised partnerships, and the sky. The act is designed for auditing companies, if not written by them, not the companies that are being audited. The requests the auditors are making are going to cause more harm then good. Yes, the requests sound excellent on paper, but will create a huge mess on the ground. The implementation of this Act is also being unnecessary rushed, probably for political reasons. DO NOT RUSH THIS! Fixing the mess will be much more expensive.
I am also having some trouble finding the exact places that outline all this requests mentioned by the Auditor. Perhaps, the Act simply gives the auditor control, and outlines that the auditor will be partial and correct. The Act then simply assumes that the auditor is right in his statements, and the company is required to comply.
If you take away anything, question everything. The auditors are following subject lines rather than diving down and understanding the text.
Compliance is, of course, required by law, but it should be done in a way that develops a limber organization that is able to adapt and involve. Rather than, an organization stuck in a paper trial and an ever evolving mountain of red tape.

Distributed Groove

I spent my day troubleshooting JGroups. For those unfamiliar, JGroups is a open source middleware system. The problem was that sometimes when a client system is restarted, the client would fail to see the cluster and instead become a coordinator of its own cluster. After a bit of research, the problem ended up being connected with long garbage collection delays on the real coordinator. This caused the server to not respond to heart beat requests, which in turn caused the client to think that it was alone and therefore become its own coordinator in its own cluster.

To solve the problem, I started looking through the JGroups source code and I stumbled upon a reference to the Lamport timestamp algorithm. I remember studing the algorithm in school. The basic premise is an ability to understand logical order of messages in a distributed environment based on a concept of time. His paper goes into quite a bit of detail, some of it awfully trivial, and other awfully complicated. This brought me to his website, where I discovered a stock pile of research papers.

He covers a lot of very interesting concepts, most of it some what over my heard. The bizantine systems are very interesting: the ability to write systems that can react to any type of error. He also goes in to describe a truly parallel garbage collection algorithm, something that would be quite nice in Java.

It's very interesting. Most of the code being written these days, myself included, is written to get it out quickly, and cheaply. The code does what it supposed to do, but is by no means very efficient or bullet proof. It does the work, but is at best a temporary solution. Definately not elegant. Then I get to see all these research papers dealing explicitely with the elegance of programming. It is a nice feeling: raw computer science.