Fri 07 May 2004
Bug in Postfix Enabler 1.1 Beta
Category : Commentary/pfe1dot1bug.txt
Now that I have more people testing Postfix Enabler 1.1 Beta, I've just had a bug report. It affects people who're using Postfix Enabler for the first time and also trying to install SpamAssassin, all at one go.
I have a bug that caused SpamAssassin not to be activated for such cases, but this bug doesn't affect those who are installing SpamAssassin on top of a mail server that had already been set up by Postfix Enabler.
It's hard to explain but I've just fixed it.
So, given enough eyeballs, all bugs are shallow, didn't they say?
The Feedback Loop
Category : Commentary/feedbackLoop.txt
I did an experiment with the Postfix Enabler page, when I felt sure that the new beta release of Postfix Enabler was doing okay in real-world use.
I added a line to that page, announcing the existence of the beta and providing a link to it. I placed the line below the version release notes and above the first graphic, where it would be seen when the page first loads without the reader having to scroll to it. But, other than that, I didn't take any special care to highlight it, e.g., I didn't set any of the keywords to bold, etc.
And I monitored the web server log for a couple of days.
No follow through. Very few people, among the many who visited the page, actually clicked through to the beta release page.
Then I made a couple of very simple changes. I added the words "SpamAssassin", "anti-virus", and "mail traffic statistics" to the line, and set the keywords to bold.
Now, the click-through is almost 80% (okay, at least better than 50%).
It's so interesting to be able to do things like this. The key is having a tracking tool you can use so that you can take an action and then track the response to that action.
In this case, the tool is a very simple web server traffic log that I wrote. It doesn't even do any consolidation or analysis. It simply lists the web server hits in reverse chronological order, albeit in a nicer format than you'll get looking at the actual server logs.
But, the point is, you can build feedback tools into almost any information system that you're using. And, my observation is, very few users understand just how much power you can get, when you look at information systems in terms of feedback loops.
For example, in an insurance system, the feedback loop is established through monitoring the claims coming in, in parallel with tracking the policies that are being sold. We've built systems that correlate the claims with the policies that resulted in those claims, and put them all in the same window. But we've observed that they're not being used in the way we designed them, simply because claims were done by the claims handling department, and policies were sold by the sales department, and never the twain shall meet.
So how are prices set? By pegging the prices against what the competition is charging. But the competitors may be catering to different sets of clientele resulting in a different claims experiences. The irony is that the users actually have better information, right under their noses, to prove or disprove this thesis. In any case, they should be able to work out, statistically and in much quicker time than they could employing third-party actuaries, the prices to charge to cover the costs of the claims. The feedback loop gives them eyes to see so that they can navigate their way to profitability. But it's not being used
So, the next thing is to ask is : is this peculiar only to Singapore - that we have somehow much dumber people. But we've worked for years with the multi-nationals - French, Germans, and the Americans (as in US of A) - and I believe the problem could be universal.
I think it's due more to the dismal state of the IT industry, where the emphasis is on technology rather than the information. We should understand that we're really in the business of understanding information, and technology is just the tool.
I believe the users can be persuaded that there's a better way. Sure, a lot of people just want to go through the motions and get paid each month - if they can get away with it. But you can start with the proposition, "Wouldn't you want to earn more, each month? We can do it if we're more profitable", and take it from there.
But getting the IT department to change - to stop blocking initiatives that didn't originate from Redmond - that's a harder thing. Try talking about understanding information when every IT guy you meet wants to talk about .Net and Visual Basic, and making obeissance to Bill Gates.
You can change things if you can get a lot people moving in sync with you. But you can get bogged down with "due diligence" and all that sort of oversight, especially when the "Mac Way" of doing things you are trying to cultivate among the users start to threaten the authority of the IT department.
Quoting this MacNewsWorld article : "... it's not that hard to support the idea that we tend to value the wrong kinds of expertise in deciding who the IT experts are ... IT decision-makers, the people whose expertise led to the rapid rise of the IBM PC and blocked Apple's early effort to serve the enterprise computing market ... that kind of expertise, in which the wrong people apply inapplicable experience to make wrong decisions..."
Unfortunately, it's these kinds of people who're controlling the IT industry discourse, deciding what is important and what's not, what is standard, and what's not. People like Rob Enderle, ironically from the same journal.
So what can we do? Quoting the MacNewsWorld article again, "In the short term, nothing. The people in charge in the data centers will perpetuate their ideas until younger companies with smarter leadership do a sufficiently better job of meeting consumer needs either to put their employers out of business or take them over."
But, I may be dead by then. "In the long run, we're all dead."