Daring to be the same
By user12625760 on Feb 17, 2005
Today was different. A customer came to see us, which in my job is rare, too rare. The high spot for me was watching a colleague do his Dtrace demo, which is highly interactive with the audience, not on his laptop, but on our production Sun Ray server. None of the users noticed even when he traced every call to mutex_enter, which even as it was being typed I did wonder if it was wise.
The other thing to come out was the question of when to be different. The customer has a highly customised environment with minimal packages installed and no “unneeded” daemons running. Which is fine, there are good reasons to do this, but I just had to ask, why? What was the business reason for not running each daemon and not installing each package? Well it was to reduce risk, risk of security breach and reduce the amount of stuff they had to support. However in reducing risk they had opened up a number of problems with the system, it ran, but there were problems with a number of subsystems that would not have been seen had the system been left alone. What in my opinion was missing from the risk assessment was the risk of being different. By heavily customising the systems to a minimal system they became so different from any other system that they are almost guaranteed to find problems that are not seen by anyone else.
It is not to say that this should not work in an ideal world, but this is not an ideal world. Running large systems is about risk management and reducing the unexpected. I hope that the customer went away with a better understanding of the risks that are exposed by being different. If being different does not get you an edge over your competitors then dare to be the same.