Ockham's Razor and IT
Ever heard of Ockham's Razor? Of course you have. No, it's not a new gadget that will topple the billion dollar disposable shaving industry, but a principle.
Except that many get it wrong..
Many think Ockham's Razor is, "Simpler is better." Alas, it's not quite so simple. Wikipedia summed it up with:
Among competing hypotheses, the one with the fewest assumptions should be selected.
It's not saying that simpler is better, but that given alternate hypotheses that satisfy constraints, the simplest one should be selected. "Simplify, but not too much," in other words.
Years ago it was expected that a system administrator wore many hats. We managed the mail services, maintained file shares, added storage, ran backups, wrote usage reports. In the fledgling days of the Internet, we were even web masters and programmers as the need arose.
As IT grew, specialization naturally occurred. Things that were once just a routine part of an administrator's week became specialized disciplines. Maybe the admin who was particularly adept with tuning the NICs on a Sun E6500 became a network engineer. Maybe the operator who helped update the procmail rules and knew sendmail became a messaging solutions expert.
Today, some of the old school admins (the BOFHs, the sysops) look at these highly specialized titles and chuckle.
And that's a mistake.
The IT infrastructure has become several orders of magnitude more complex than it was in the past. The amount of change in a year is so great that -- to be on top of our fields -- we are constantly in class and constantly learning and experimenting with technology.
If we're really good, we make the complexities of our discipline transparent to our peers. If we manage the OS, we are thankful that there are storage experts who worry about MTBF rates and logarithmic growth year over year. We are glad that the business continuity experts figure out how to recover a server when an application owner completely neglected to plan for backups. Heck, I'm grateful that someone else figures out optimal MTUs and wires together disparate networks riding on competing vendors and technologies. These are just the complexities I know about. The unknown unknowns are thankfully hidden away from me by other engineers.
And there's the rub...
These really good engineers, by making the complexities seem simple, may convince others that what they do is indeed simple. And we all know what happens next. During a planning meeting someone dismisses the complexity. "I can buy a 2TB disk for $100. Why does my storage cost $2K?" Or, "Why can't you load Ubuntu? You can download it for free."
In other words, they've simplified too much.
There are no easy solutions. DevOps and CI and Scrum and other methods can be used to foster communication between different specializations. They can work but are highly dependent on corporate culture.
Most importantly, I realize that respect for one's peers is the only way to manage the complexity without over-simplifying. Assume that what the others do is as equally complex as what I do and where I think it may be simple, assume that they may be going to great lengths to make that complexity manageable to others outside their discipline.
What do you think?