January 29, 2007
For the Doubters
I used to argue with people every once in a while who claimed that, of course, Microsoft was out to make a profit, but that they were not trying to destroy their competition and lock consumers into their products because that would be wrong, and Microsoft's competitors are just ticked off that they're losing to Microsoft. Oh, really?
Yes. Yes, it Was
There are some things so stupid that only an academic could believe them. One would think that being an expert on French history would have taught him the dangers of appeasement. If he has deeper reading in European history that led up to France, he should understand the long-term danger posed by radical Muslims. Moreover, he very quickly gives away his fundamental misunderstanding of the threat and the "overreaction" he derides:
Certainly, if we look at nothing but our enemies' objectives, it is hard to see any indication of an overreaction. The people who attacked us in 2001 are indeed hate-filled fanatics who would like nothing better than to destroy this country. But desire is not the same thing as capacity, and although Islamist extremists can certainly do huge amounts of harm around the world, it is quite different to suggest that they can threaten the existence of the United States.
Well, the enemy (at least he calls them that!) demonstrated the ability to kill our civilians in large numbers, and their willingness to do so is not disputed even by Professor Bell. Is the Professor then suggesting that we wait until they have the ability to kill us in total before ending the threat is something other than "overreaction"? Is the Professor suggesting that waiting until the only possible way to end the threat is genocide is somehow measured and well-considered reaction?
Finally, and above all, this is exactly the reason we are fighting a slow war: to prevent the kind of genocide that would be necessary if we failed to act until the enemy has the capacity to annihilate us.
The Awe and the Mystery
Via Instapundit, I found this majestic speech by Michael Griffin. This encapsulates, very clearly, what I feel about the space program, and also why I think that it will be private interests rather than NASA who get us into space permanently and for anyone who wants to go.
January 25, 2007
Why do they Call it Islamophobia?
"Islamophobia" implies that one is afraid of Islam, although it's usually conflated into fear of Muslims, because what's really being talked about is usually being against the tenets of Islam. Clearly, they cannot use "islamist" the way they use "racist", because "islamist" is taken. In fact, it's taken by the very people who inspire what is usually called "islamophobia", but is really anti-islamism.
And I am, frankly and proudly, anti-islamist, the same way and with the same pride that I am anti-fascist and anti-communist: I am against any systematic state control of private lives, and I am particularly against any state control of religion (which in a sense is a tenet of islamism, fascism and communism all.
Why, yes, I have been listening to NPR. Why do you ask?
January 20, 2007
That was Different
At 4:21 am yesterday, something happened. Something electrical. Something that fried the power supply on my server (which is odd because it's on a good-quality UPS and other things on the UPS were fine) and also fried my wireless extender. I got a power supply this afternoon, brought the server up, and (blessed be the creators of the UNIX operating system and their Linux acolytes) all is once again well.
January 15, 2007
When Ad People Abuse Drugs
So here, via Brian Tiemann, is an old promo tape for Windows/386. I don't know what's best about this video. It's a close race between Microsoft's admission that OS/2 is better than any then-current Microsoft OS, the talking up of Chart (supposed to be Microsoft's Lotus 1-2-3 killer, until MS bought Excel) as some kind of second coming, the takeover by crack-smoking monkeys (as described by the guy who posted the video) 7 minutes in, or the apparent surprise of Windows/386 that it's PRINTING! Enjoy.
January 9, 2007
That's Just Cool
Apple released a cell phone — ummm, maybe I should say cell phone/iPod/mobile computer/camera — today, and I'm almost sold. This is the first phone since the Samsung i500, which I currently use, that has everything I want in a phone: good phone in a reasonable form factor (I'm assuming a little on the Apple form factor, not having held one yet), built-in contact list sync'd to my computer, web browser and various miniature productivity applications.
The iPhone goes further, adding the camera (which would be cool for a personal phone, but might be enough to keep me from getting one: many of my clients wouldn't let me bring a camera into the building) and the iPod (though at only 4 or 8 GB, it's a far cry from my current 30GB model in terms of storage). The storage issue is actually significant, because even with 8GB, I'd have to select what I wanted available beforehand, especially if that 8GB is used not just for data, like songs, but also for applications that aren't built into the phone.
Being run off of OS X would be a definite plus, because I'm very familiar with the OS internals, and could write stuff I need that other people don't provide. Plus, it's a GSM phone, which actually bit me last year when I had to take a trip to Europe on notice too short to get a GSM phone to take with me. The SMS support, basically iChat on the phone, would be useful to me, and is something the i500 doesn't have (it's receive-only for messaging). Finally, the 5 hour talk time is nice, but doesn't equal the extended battery on my i500, which would be annoying when I'm traveling, particularly because that's when I'm likely to be using the maps and browser, as well as other widgets like local weather.
The phone is only offered in the US through Cingular (as an aside, I hate this practice of cell phones being locked in to particular carriers), and the biggest unknown is the service plan setup: how much will service cost, and will I be paying by the minute for data as well as voice? Will I be able to get free roaming (well, no-extra-cost roaming) and no-charge family-to-family calling?
Frankly, the odds of me getting one of these, at least for now, are pretty low. But I can see the attraction, and I wouldn't be surprised if I changed my mind with the next generation of this device.
In case you were unaware, and a propos of nothing, the best resource on space vehicles, personalities and plans is Encyclopedia Astronautica. Why, yes, I did just spend over an hour browsing at near-random after looking something up. Why do you ask?
January 7, 2007
Unsurprising to Me
Wizbang notes that the Sunday Times is reporting Israeli plans for a nuclear strike on Iran to cripple the Iranian nuclear program. While this report may or may not be true, it's certain that the possibility is unsurprising to me, since I have been writing about it off and on for at least two years. But it's likely that the Sunday Times report is not any advanced warning of imminent attack; more likely it's a strategic leak designed to make Iran think seriously about the possible consequences of its intransigence.
January 4, 2007
Working with enterprise IT systems is hard. Sometimes, it is very, very hard. There are a lot of reasons for this, but regardless of the reasons, the combination of difficulty and impact on the bottom line would lead the naïve to conclude that all IT people are uniformly quite bright. This is, sadly, not the case. Many IT people are quite bright, and some are truly exceptional, but this is hardly more of a universal attribute in enterprise IT work than it is in the general population.
IT is not unique in this; in engineering, for example, there are more than a few rocket scientists who are, actually, pretty average intellectually. But engineering generally is a mature field; it has evolved measures to deal with the need to design things that could kill a lot of people if events go awry, using people who are, well, just people. IT is immature, and still depends on above-average skills to get decent results without unaffordable costs. This is, perhaps, a key reason why 90% or more of large IT projects at large companies fail to be completed on time and on budget (over 30% fail to be completed at all!), and even then often lack more than half of their originally-intended feature set.
Since we don't have very much professional legacy of good practice, in comparison to older technical fields, IT managers, project managers and architects generally have to do a lot of muddling through. Frustration with this is, in fact, the core motivation behind the software engineering movement. Part of that muddling through is understanding the kind of people you have to deal with on a daily basis. In IT, there are essentially four types: bureaucrats, magicians, artists and engineers.
Bureaucrats are those people who are entirely or nearly entirely process oriented. To a bureaucrat, a schedule, list or budget is far more meaningful than whether or not the system they are developing or administering actually works. Bureaucrats love arbitrary dates, large numbers of technically-meaningless milestones, and the illusion of control. In fact, to a bureaucrat, controlled failure is more valuable than chaotic success. Bureaucrats typically do not last long as either administrators, technicians or developers; they quickly migrate into management, where they can do the most harm. The rest end up working in call centers, data center operations, deployment or technical audit (in all of which they excel).
Magicians don't actually understand what they are doing. They have some finite list of incantations, sufficient to grant success at taming certain demons. If you've ever come across a system administrator whose idea of fixing a broken system is to restore it from the OS up, going through each installation manual along the way and finishing with restoring the last good data backup, you've seen the magician in action. Pretty much everyone starts out as a magician, and all of us are magicians in some areas; what distinguishes the true magician is that he will always be a magician in a few areas, and utterly unknowing in all other areas. Coders who cannot understand the implications of what they are coding, system/network/database administrators with a one-hammer toolkit, and architects who are lost when a machine is set in front of them and they are actually expected to use it are common examples of the breed.
In comparison to the first two groups, the artist truly understands everything about what he is doing. To an artist, an enterprise system is a symphony, and he is the conductor (and plays all the instruments). If you cannot understand that his code is dependent on the byte order of an undocumented network device in Pittsburgh, it just shows that you don't know enough to speak on his level. If you are appalled when you determine that he spent a month rewriting a rarely-called but compatibility-critical standard system function in assembly and with a non-standard interface (for just that extra bit of performance, and besides, it was a total kludge), or that he is using print queues with a custom back end as a network messaging interface "for convenience", well, that just shows that you aren't worthy. These guys are gold, but I suggest you keep them in the back room, and filter all of their output through someone with more interest in non-geniuses being able to use the systems. Under no circumstances allow an artist to deal with end users, customers, or people whose opinion you value.
Probably even more rare than the artists are the engineers. I don't mean people with "engineer" in their title (often glorified coders or system administrators), but the ones who understand the need for discipline, reliability, repeatability, and solid design. Engineers are in love with six sigma, and actually understand the math involved as well as the pretty pictures that express the math; or alternately, can tell you why six sigma is all fine and good, but could be improved by.... Engineers are the ones who fix a problem once, and document everything. They are also the ones who do the vast majority of the useful work on a project. If you find yourself in possession of an engineer, make sure that they are involved in training and in hiring new people, and under no circumstance underpay them; you do not want them to end up working for your competition. (Actually, that goes for the artists, too; but you can put engineers in charge, while artists will alienate all of your other employees if they are in charge.)
In the total IT population, the proportion is probably about 30-50% bureaucrats, about 40-60% magicians, and maybe 5% each of artists and engineers. The best combination is to have your senior managers be a mix of bureaucrats and engineers; your line managers and architects be almost entirely engineers; your deployment, operations and call center people be mostly bureaucrats; and your developers be artists and engineers. Pair up the magicians with the less-experienced engineers (who will usually be good team leads in any case) or with the more tactful artists, and you'll end up turning many of them into engineers or artists; the remainder will eventually move on, voluntarily or otherwise.
A kludge (usually pronounced klooj, with the oo and in food) is something thrown together thoughtlessly, and usually quickly, which works, more or less, but which is generally ugly, and may be either underperforming or missing functionality or both. Examples include quick scripts for copying files across the network as a sort of poor-man's backup system, or using system components for purposes for which they were not designed (such as using print queues as a network messaging service — and yes, I've actually seen this done). A kludge is not necessarily broken, but it is necessarily inelegant, often even ugly, and generally offensive to the sensibilities of all right-thinking IT people. In other words, the term is usually an insult.
An enterprise, in IT terms, is any large, widely-dispersed or otherwise complex organized undertaking. A simple example would be a single organization with employees and systems at more than one site, while a more complex example would be a group of companies cooperating on a joint venture of some sort. The word is, sadly, widely misused, generally as a synonym for "corporation". But "enterprise" implies a much broader context than that.
Of course, this is an example of overloading a non-IT term (for any given business venture), which is part of the source of confusion. In IT, an enterprise is always either large, which is inherently complex, or is complex due to some feature of organization or distribution.
To be more formal, a good general definition of "enterprise" would be any relatively large (say, more than 1000) set of people involved in a joint undertaking using shared IT resources, and meeting any of the following criteria:
- People involved in the undertaking are dispersed at more than two sites, widely separated, with no more than one fourth of the people at any given site.
- IT systems used by people for the undertaking are located at widely separated sites.
- Multiple distinct IT systems are used in the undertaking, and they share infrastructure components, user identities, management practices, administrative reporting structures and/or data.
- IT systems used by people in the undertaking are required to be available 7x24.
Fundamentally, each of these criteria introduce complexity. Most enterprises share meet all of those criteria. And for enterprise-level IT workers, vendors and management, it is that complexity that requires the need for a new term. While some critics use the term sneeringly, to mean an overly-complex system or application, the reality is that it is a useful term for differentiating systems of high complexity from those that are relatively easy to maintain, or whose availability is not critical.
To use one example, consider the web server this site is hosted on. It is a single server, running Linux off of two not-entirely-mirrored disk drives, in the basement of my house, with a single fairly reliable internet connection (that is, the connection is down less than an hour per week, on average). That is not an enterprise configuration. Let's say that I wanted to have the system available continuously from anywhere under any circumstances; to do that, I would have to eliminate single points of failure, and reduce the possibility of failure even among duplicated components. How would I do that?
First, I would have to have web servers at two different, widely-dispersed sites, so that a natural disaster couldn't shut both (or the networks that connect both) down from the same cause. Given power outages recently, let's say that I host one in Michigan (as now), and the second in Texas. The servers would have to get larger, because they would need more disk drives to allow more redundancy in case of drive failure; and would have to have two power supplies, duplicated processors and memory and so forth. In addition, each would need at least two network connections, through different routers connected to network providers that use different connection points for their physical data links. I would have to have more, and more widely-dispersed, name servers to serve their naming information, and would have to have significantly more complex wiring to connect all of these things. This all also implies both having a dedicated machine room with special air conditioning, racks and wiring harnesses, as well as having a person available 7x24 at each site to administer the systems (which means in practice at least three people per site, and probably more). Finally, I would have to change blogging software, because this software does not have the functionality to publish simultaneously to multiple servers from the same backend database (particularly with dynamic pages, where faking it is much harder because you have to go back to the same database instance). I would have to have a significantly more reliable backup system, preferably with some near-online storage capability and automated offsite library management. I would have to get some kind of distributed authentication system in place, preferably with unified provisioning via an identity management system (of similar complexity to the web server example given).
That is actually a poor example, though, because in a real enterprise, this would be one of many interconnected systems, all of which would include multiple servers, usually on different platforms and often managed by different organizations with not-quite-synchronized goals and incentives. It should, though, give an indication of the complexity of enterprise-level systems in comparison with what one might use for one's personal use. Most small organizations are significantly closer to what I have at home than to what would be suitable for an enterprise.
January 3, 2007
One of the problems with explaining any technical field is that there is a large amount of jargon involved, because both precision and concise expression are necessary and jargon provides that. This is certainly true of the IT (information technology — see what I mean about jargon?) world, where the amount of shared jargon is daunting, and where more than a few conversations are almost entirely conducted in acronyms. To make matters worse, or at least more confusing, each enterprise develops its own jargon, or its own definitions of fairly standard jargon, as it goes along. Finally, adding insult to injury, the same term is often overloaded with multiple, similar but distinct meanings. The resulting terminological ambiguity is sometimes comical, and often expensive (miscommunication costs money to fix the resultant mistakes).
When I decided that I really do want to talk more about what I do for a living, the first thing I wanted to address was what makes an enterprise so different from any other computing environment, and why enterprise IT is so difficult to get right. But I realized that in order to do that, I would have to either heavily footnote the entry, or start by explaining a very large number of terms, which would heavily distract from the point.
Fortunately, there is a better way: a jargon dictionary. Such already exist (see here and here for a couple of good ones), but none of them are very complete, and mostly their definitions are themselves laden with jargon. As a result, it appears that I'll just have to write up the jargon as I go along, in entries separate from the topics I'm actually discussing. My definitions may not be canonical, but they will at least allow you to figure out what I'm talking about.
So consider this post both an introduction and a request. Are there any computer or IT terms that baffle you? Ask in the comments, and I'll define them, without unexplained jargon and with examples and maybe even color glossy photographs.