A few Magenic colleagues  and I happened to be in the office at the same time today and were discussing what makes a good software consultant.  We arrived at the idea that there are certain archetypes that can be associated with our profession.  Consulting and independent contracting require a peculiar combination of skills which are not always compatible: leadership, salesmanship, problem solving, commitment, patience, quick thinking, geekiness, attention to detail, attention to vision, and so forth. 

As a consultant, one is often both the salesman and the product being sold, and it requires a bit of a split personality to pull both off well.  Most consultants are able to do well with certain aspects of consulting but not others.  It seemed to us, however, that if we could identify certain “types” of consultants rather than try to identify the particular skills that make up a consultant, we would arrive at something approaching a broad spectrum of what consulting is all about.

After a bit of work, Whitney Weaver, Colin Whitlatch, Tim Price-Williams (who needs a blog because he knows too much about the entity framework not to share)  and I came up with the following list of consulting archetypes and the qualities that exemplify each one. 

For our unit test, we then tried to match consultants we know first with who they think they are and then with who they actually resemble.  It worked out pretty well, and so we thought we’d turn the idea loose.  (I turned out to be a weird mix of MacGuyver and the Jump-To-Conclusions-Guy, though I also have a savior complex.)

See if any of the following archetypes matches people you know.  And if you think we’ve left an important archetype out of our catalog, please let me know in the comments.

 

Jack Bauer

Jack is the ultimate get-things-done guy.  This is in part because he takes the full weight of any project on his own shoulders.  He is admired by everyone he encounters for his dedication and competence. 

He also comes across as a bit harsh, however, so we can’t really say he has good soft skills.  Some consider consultants like him to be a bit too good to be true.

 

House

House is great at diagnosing any problem.  He is methodical and thorough while at the same time he is able to think well outside of the box. 

He is also a bit of a dick and will turn on you when you least expect it.  On the other hand, when he throws you under the bus, at least you’ll know it wasn’t personal.

 

Maverick

Maverick is charismatic as well as intensely competitive, though his arrogance tends to put people off.  If you think a task will take two weeks, he’ll claim it can be done in two days.  If you estimate that something will take two days, he’ll insist he can do it in two hours.

He always manages to be successful though no one is sure how. 

 

Sarah Connor

Sarah thinks quickly on her feet and is an extraordinary problem solver.  She has a great mix of soft and technical skills. 

Sadly, she tends to get the people around her killed.  Consultants with skills like hers seem to take on a lot more risk than the rest of us would, and we all reap the consequences.

 

Don Draper (Mad Men)

Don has infinite charm and is a perennial winner.  Women love him and men want to be his friend.

He is also clearly hiding something from everyone, and is haunted by the notion that he is ultimately a fraud.

 

 

Neo

Neo can re-program reality.

Some consider him to be wooden.  He also has a bit of a savior complex.

 

The Chick from Terminator 3

Pros: She’s smokin’ hot.

Cons: She will kill you at the drop of a hat.

 

MacGuyver

MacGuyver is a jack-of-all trades, the kind of consultant you want on any project.  He also has great hair.

He tends to be a bit of a one-man-show, however.

 

Kramer

Kramer has the “vision” thing.  He’s the one who will envision and lay out the entire architecture of the project in the first few days despite other people’s misgivings.

Unfortunately Kramer has poor follow-through.  You’ll be living with his architectural decisions long after he’s moved on to bigger and better things.

 

Benjamin Linus

Ben has excellent soft skills.  He is a master manipulator.  He can turn any situation to his own advantage.  In a tough negotiation, he’s the consultant you want at your side.

On the other hand, he is pure EVIL and cannot be trusted.

 

Alec Baldwin in Glengarry Glen Ross

“Second prize is a set of steak knives.”  Alec is a motivator.  Other people quiver in his presence.  We all know that sometimes you have to be an asshole to get things done.  Fortunately a consultant like Alec loves that part of the job.

We can assume that he will eventually flame out, as people of this type always do.  Sadly, no one will really feel sorry for him when this happens.

 

Cartman

Eric Cartman has strong survival skills and is highly self-confident, both of which enable him to accomplish his sometimes overly ambitious schemes. He also aways has a private agenda.

Because of this, he tends to make himself a bit of a target, while his single-minded pursuit of his own ends can cause serious problems for other consultants.

 

George Costanza

Everything always seems to blow up on George.  He is also high maintenance.

On the upside, he is generally considered non-threatening, which can sometimes be a very good thing in consulting.

 

The Jump-To-Conclusions-Guy

This guy is eternally optimistic.  He considers himself to have excellent people skills.

He does not have excellent people skills.

 

 

Vanilla Ice

Vanilla Ice is the archetypal one-hit wonder. 

He did something important back in 1990 and has been living off of that one success ever since.  Then again, not everyone gets even that one success, so don’t judge him too harshly.

 

Lumbergh

Lumbergh is the anti-Jack Bauer.  He is a human deflector shield, and while you’re not looking he’ll manage to blame you for his screw ups.   When he throws you under the bus, you’ll know that it really was in fact personal.

The best that can be said of Lumbergh is that you don’t run into too many Lumberghs in software consulting.

 

 

We are so happy with this catalog of consulting types that we are thinking of using it in our local vetting of new-hire candidates.  Given the broad range of technical skills people can have, it seems rather unfair to try to label new-hires as “senior” or “junior” or anything like that.  What we’re looking for, after all, is a good fit for our local office, and the best way to do this is to, say, determine that we need another Maverick or a Sarah Connor or a Neo, and to try to find the right person following the guidelines above.

Moreover, when we tell our clients that we are sending them our A-Team, we can mean it literally: they are getting one Alec Baldwin, one Don Draper,  a MacGuyver and a Jump-To-Conclusions-Guy.  On the other hand, if someone wants the cast from Seinfeld, we can fill that order, too.

 

 

In the same lecture excerpted previously, William James provides an earthy example of what he means by pragmatism.  It involves squirrel.

Some years ago, being with a camping party in the mountains, I returned from a solitary ramble to find everyone engaged in a ferocious metaphysical dispute. The corpus of the dispute was a squirrel--a live squirrel supposed to be clinging to one side of a tree-trunk; while over against the tree's opposite side a human being was imagined to stand. This human witness tries to get sight of the squirrel by moving rapidly round the tree, but no matter how fast he goes, the squirrel moves as fast in the opposite direction, and always keeps the tree between himself and the man, so that never a glimpse of him is caught. The resultant metaphysical problem now is this: DOES THE MAN GO ROUND THE SQUIRREL OR NOT? He goes round the tree, sure enough, and the squirrel is on the tree; but does he go round the squirrel? In the unlimited leisure of the wilderness, discussion had been worn threadbare. Everyone had taken sides, and was obstinate; and the numbers on both sides were even. Each side, when I appeared, therefore appealed to me to make it a majority. Mindful of the scholastic adage that whenever you meet a contradiction you must make a distinction, I immediately sought and found one, as follows: "Which party is right," I said, "depends on what you PRACTICALLY MEAN by 'going round' the squirrel. If you mean passing from the north of him to the east, then to the south, then to the west, and then to the north of him again, obviously the man does go round him, for he occupies these successive positions. But if on the contrary you mean being first in front of him, then on the right of him, then behind him, then on his left, and finally in front again, it is quite as obvious that the man fails to go round him, for by the compensating movements the squirrel makes, he keeps his belly turned towards the man all the time, and his back turned away. Make the distinction, and there is no occasion for any farther dispute. You are both right and both wrong according as you conceive the verb 'to go round' in one practical fashion or the other."

Altho one or two of the hotter disputants called my speech a shuffling evasion, saying they wanted no quibbling or scholastic hair-splitting, but meant just plain honest English 'round,' the majority seemed to think that the distinction had assuaged the dispute.

Over the past ten years or so the software development world has split itself between two extremes of temperament.  One is pragmatic while the other, for lack of a better term, is purist.  This is a division which actually happens again and again from one year to the next, with members of one party sometimes becoming members of the other, and practitioners of one philosophy in one technical domain becoming practitioners of the other under other circumstances.

This is not a division of temperament unique to programming of course, though it perhaps gets a little more play there than in other fields these days.  As a matter of interest and of clarification, I thought I might provide some excerpts from William James’s work Pragmatism: A New Name for Some Old Ways of Thinking from 1907:

“The history of philosophy is to a great extent that of a certain clash of human temperaments. Undignified as such a treatment may seem to some of my colleagues, I shall have to take account of this clash and explain a good many of the divergencies of philosophers by it. Of whatever temperament a professional philosopher is, he tries when philosophizing to sink the fact of his temperament. Temperament is no conventionally recognized reason, so he urges impersonal reasons only for his conclusions. Yet his temperament really gives him a stronger bias than any of his more strictly objective premises. It loads the evidence for him one way or the other, making for a more sentimental or a more hard-hearted view of the universe, just as this fact or that principle would. He trusts his temperament.”

. . .

“Yet in the forum he can make no claim, on the bare ground of his temperament, to superior discernment or authority. There arises thus a certain insincerity in our philosophic discussions: the potentest of all our premises is never mentioned. I am sure it would contribute to clearness if in these lectures we should break this rule and mention it, and I accordingly feel free to do so.”

. . .

“Now the particular difference of temperament that I have in mind in making these remarks is one that has counted in literature, art, government and manners as well as in philosophy. In manners we find formalists and free-and-easy persons. In government, authoritarians and anarchists. In literature, purists or academicals, and realists. In art, classics and romantics. You recognize these contrasts as familiar; well, in philosophy we have a very similar contrast expressed in the pair of terms 'rationalist' and 'empiricist,' 'empiricist' meaning your lover of facts in all their crude variety, 'rationalist' meaning your devotee to abstract and eternal principles. No one can live an hour without both facts and principles, so it is a difference rather of emphasis; yet it breeds antipathies of the most pungent character between those who lay the emphasis differently; and we shall find it extraordinarily convenient to express a certain contrast in men's ways of taking their universe, by talking of the 'empiricist' and of the 'rationalist' temper. These terms make the contrast simple and massive.

“More simple and massive than are usually the men of whom the terms are predicated. For every sort of permutation and combination is possible in human nature; and if I now proceed to define more fully what I have in mind when I speak of rationalists and empiricists, by adding to each of those titles some secondary qualifying characteristics, I beg you to regard my conduct as to a certain extent arbitrary. I select types of combination that nature offers very frequently, but by no means uniformly, and I select them solely for their convenience in helping me to my ulterior purpose of characterizing pragmatism. Historically we find the terms 'intellectualism' and 'sensationalism' used as synonyms of 'rationalism' and 'empiricism.' Well, nature seems to combine most frequently with intellectualism an idealistic and optimistic tendency. Empiricists on the other hand are not uncommonly materialistic, and their optimism is apt to be decidedly conditional and tremulous. Rationalism is always monistic. It starts from wholes and universals, and makes much of the unity of things. Empiricism starts from the parts, and makes of the whole a collection-is not averse therefore to calling itself pluralistic. Rationalism usually considers itself more religious than empiricism, but there is much to say about this claim, so I merely mention it. It is a true claim when the individual rationalist is what is called a man of feeling, and when the individual empiricist prides himself on being hard- headed. In that case the rationalist will usually also be in favor of what is called free-will, and the empiricist will be a fatalist-- I use the terms most popularly current. The rationalist finally will be of dogmatic temper in his affirmations, while the empiricist may be more sceptical and open to discussion.

“I will write these traits down in two columns. I think you will practically recognize the two types of mental make-up that I mean if I head the columns by the titles 'tender-minded' and 'tough-minded' respectively.”

THE TENDER-MINDED	THE TOUGH-MINDED
Rationalistic (going by 'principles')	Empiricist (going by 'facts')
Intellectualistic	Sensationalistic
Idealistic	Materialistic
Optimistic	Pessimistic
Religious	Irreligious
Free-willist	Fatalistic
Monistic	Pluralistic
Dogmatical	Sceptical

 

“Pray postpone for a moment the question whether the two contrasted mixtures which I have written down are each inwardly coherent and self-consistent or not--I shall very soon have a good deal to say on that point. It suffices for our immediate purpose that tender-minded and tough-minded people, characterized as I have written them down, do both exist. Each of you probably knows some well-marked example of each type, and you know what each example thinks of the example on the other side of the line. They have a low opinion of each other. Their antagonism, whenever as individuals their temperaments have been intense, has formed in all ages a part of the philosophic atmosphere of the time. It forms a part of the philosophic atmosphere to-day. The tough think of the tender as sentimentalists and soft-heads. The tender feel the tough to be unrefined, callous, or brutal. Their mutual reaction is very much like that that takes place when Bostonian tourists mingle with a population like that of Cripple Creek. Each type believes the other to be inferior to itself; but disdain in the one case is mingled with amusement, in the other it has a dash of fear.”

And here’s the bait and switch portion of this post.  When we speak of being pragmatic today, we generally mean by it the items in the second column above.  For James, however, the term describes a way of looking at the world that resolves disputes between the possessors of these two temperaments.  It is the tertia via.

“The pragmatic method is primarily a method of settling metaphysical disputes that otherwise might be interminable. Is the world one or many?--fated or free?--material or spiritual?--here are notions either of which may or may not hold good of the world; and disputes over such notions are unending. The pragmatic method in such cases is to try to interpret each notion by tracing its respective practical consequences. What difference would it practically make to anyone if this notion rather than that notion were true? If no practical difference whatever can be traced, then the alternatives mean practically the same thing, and all dispute is idle. Whenever a dispute is serious, we ought to be able to show some practical difference that must follow from one side or the other's being right.”

. . .

“It is astonishing to see how many philosophical disputes collapse into insignificance the moment you subject them to this simple test of tracing a concrete consequence. There can BE no difference any- where that doesn't MAKE a difference elsewhere--no difference in abstract truth that doesn't express itself in a difference in concrete fact and in conduct consequent upon that fact, imposed on somebody, somehow, somewhere and somewhen. The whole function of philosophy ought to be to find out what definite difference it will make to you and me, at definite instants of our life, if this world- formula or that world-formula be the true one.”

. . .

“There is absolutely nothing new in the pragmatic method. Socrates was an adept at it. Aristotle used it methodically. Locke, Berkeley and Hume made momentous contributions to truth by its means. Shadworth Hodgson keeps insisting that realities are only what they are 'known-as.' But these forerunners of pragmatism used it in fragments: they were preluders only. Not until in our time has it generalized itself, become conscious of a universal mission, pretended to a conquering destiny. I believe in that destiny, and I hope I may end by inspiring you with my belief.”

. . .

“At the same time it does not stand for any special results. It is a method only. But the general triumph of that method would mean an enormous change in what I called in my last lecture the 'temperament' of philosophy.”

It is a philosophy that requires us to ask, when given two temperamental approaches to the same problem, a very rude question. 

We would be required to ask “What practical difference does it make?”  On the other hand, in programming if not in other spheres, it would save an insufferable amount of time and effort were we simply to ask this a little more often.

 

The following is a parable about the difference between theory and practice, which Michael Oakeshott frames as the difference between technical and practical knowledge, found as a footnote in Michael Oakeshott's essay Rationalism In Politics.  I find that it has some bearing, which I will discuss in the near future, to certain Internet debates about pedagogy and software programming:

"Duke Huan of Ch'i was reading a book at the upper end of the hall; the wheelwright was making a wheel at the lower end.  Putting aside his mallet and chisel, he called to the Duke and asked him what book he was reading.  'One that records the words of the Sages,' answered the Duke.  'Are those Sages alive?' asked the wheelwright.  'Oh, no,' said the Duke, 'they are dead.'  'In that case,' said the wheelwright, 'what you are reading can be nothing but the lees and scum of bygone men.'  'How dare you, a wheelwright, find fault with the book I am reading.  If you can explain your statement, I will let it pass.  If not, you shall die.'  'Speaking as a wheelwright,' he replied, 'I look at the matter in this way; when I am making a wheel, if my stroke is too slow, then it bites deep but is not steady; if my stroke is too fast, then it is steady, but it does not go deep.  The right pace, neither slow nor fast, cannot get into the hand unless it comes from the heart.  It is a thing that cannot be put into rules; there is an art in it that I cannot explain to my son.  That is why it is impossible for me to let him take over my work, and here I am at the age of seventy still making wheels.  In my opinion it must have been the same with the men of old.  All that was worth handing on, died with them; the rest, they put in their books.  That is why I said that what you were reading was the lees and scum of bygone men.'"

-- Chuang Tzu

 

There is one big player in the software development world, and her name is Microsoft. Over the years many vendors and startups have attempted to compete against the lumbering giant, and Microsoft has typically resorted to one of two methods for dealing with her rivals. Either she pours near-unlimited money into beating the competition, as Microsoft did with Netscape in the 90's, or she buys her rival right out. It is the typical build or buy scenario. But with the ALT.NET world, she seems to be taking a third approach.

The premise of the ALT.NET philosophy is that developers who work within the Microsoft .NET domain should still be free to use non-Microsoft sanctioned technologies, and there is even a certain Rome versus the barbarians approach to this, with Microsoft naturally taking the part of the Arian invaders. The best solution to a technical problem it is claimed (and rightly so) need not be one provided by Microsoft, which ultimately is a very small sub-set of the aggregate body of developers in the world. Instead, solutions should be driven by the developer community who know much more about the daily problems encountered by businesses than Microsoft does. Microsoft in turn may or may not provide the best tools to implement these solutions; when she doesn't, the developer community may come up with their own, such as NHibernate, NUnit, Ajax, Windsor and RhinoMocks (all free, by the way).

What is interesting about each of these tools is that, when they came out, Microsoft didn't actually have a competing tool for any of these technologies. Instead of competing with Microsoft on her own field, the ALT.NET community began by competing with Microsoft in the places where she had no foothold. Slowly, however, Microsoft came out with competing products for each of these but the last. MSUnit was released about three years ago to compete with NUnit. ASP.NET AJAX (formerly ATLAS, a much cooler name) competes with the various Ajax scripting libraries. ASP.NET MVC competes with the PHP development world. Entity Framework and the Unity Framework were recently released to compete with NHibernate and Windsor, respectively.

Unlike the case with the browser wars of the 90's, Microsoft's offerings are not overwhelmingly better. The reception of the Entity Framework (mostly orchestrated by the ALT.NET community itself, it should be admitted) was an extreme case in point, for scores of developers including a few MVP's (Microsoft's designation for recognized software community leaders) publicly pilloried the technology in an open letter and petition decrying its shortcomings.

Microsoft, in these cases, is not trying to overwhelm the competition. She does not throw unlimited resources at the problem. Instead, she has been throwing limited resources at each of these domains and, in a sense, has accomplished what the ALT.NET world originally claimed was their goal: to introduce a bit a of competition into the process and allow developers to select the most fitting solution.

Not too long ago I came across an article that suggested to me a less benign strategy on Microsoft's part, one that involves ideological purity and software promiscuity. The ALT.NET world, one might be tempted to say, has a bit of a religious aspect to it, and the various discussion board flames concerning ALT.NET that pop up every so often have a distinct religious patina to them.

The relationship between ALT.NET-ers to Microsoft is a bit like the relationship of of Evangelicals and Fundamentalists to the world. We do, after all, have to live in this world, and we don't have the ability or the influence at all times to shape it the way we want. Consequently, compromises must be made, and the only question worth asking is to what extent we must compromise. The distinction between Evangelicals and Fundamentalists rests squarely on this matter, with Evangelicals believing that some sort of co-existence can be accomplished, while Fundamentalists believe that the cognitive dissonance between their view of the world and the world's view of itself are too great to be bridged. For Fundamentalists, the Evangelicals are simply fooling themselves, and worse opening themselves up to temptation without realizing it.

All this being background to Margaret Talbot's article in the November New Yorker Red Sex Blue Sex: Why do so many evangelical teen-agers become pregnant?  Ms. Talbot raises the question of abstinence only programs which are widely ridiculed for being unsuccessful. 

"Nationwide, according to a 2001 estimate, some two and a half million people have taken a pledge to remain celibate until marriage. Usually, they do so under the auspices of movements such as True Love Waits or the Silver Ring Thing. Sometimes, they make their vows at big rallies featuring Christian pop stars and laser light shows, or at purity balls, where girls in frothy dresses exchange rings with their fathers, who vow to help them remain virgins until the day they marry. More than half of those who take such pledges—which, unlike abstinence-only classes in public schools, are explicitly Christian—end up having sex before marriage, and not usually with their future spouse."

The programs are not totally unsuccessful.  In general pledgers delay sex eighteen months longer than non-pledgers.  The real indicator of the success of an abstinence only program, however, is how popular they become.  The success of an abstinence only program is ironically inversely proportional to its popularity and ubiquity.

"Bearman and Brückner have also identified a peculiar dilemma: in some schools, if too many teens pledge, the effort basically collapses. Pledgers apparently gather strength from the sense that they are an embattled minority; once their numbers exceed thirty per cent, and proclaimed chastity becomes the norm, that special identity is lost. With such a fragile formula, it’s hard to imagine how educators can ever get it right: once the self-proclaimed virgin clique hits the thirty-one-per-cent mark, suddenly it’s Sodom and Gomorrah."

The ALT.NET chest of development tools is not widely used, although its proponents are very vocal about the need to use them.  Unit testing, which is a very good practice, has limited actual adherence though many developers will publicly avow its usefulness.  NHibernate, Windsor and related technologies have an even weaker hold on the mind share of the developer community -- much less than the thirty percent, I would say -- an actuality which belies the volume and vehemence, as well as exposure, of their proponents.

With the thirty-one percent solution, Microsoft does not have to improve on the ALT.NET technologies and methodologies in order to win.  All she has to do is to help the proponents of IOC, Mocking and ORMs to get to that thirty-one percent adoption level.  She can do this by releasing interesting variations of the ALT.NET community tools, thus gentrifying these tools for the wider Microsoft development community.  Even within the ALT.NET world, as in our world, there are more Evangelicals than Fundamentalists, people who are always willing to try something once.

Microsoft's post-90's strategy need no longer be build or buy.  She can take this third approach of simply introducing a bit of software promiscuity, a little temptation here, a little skin there, and pretty soon it's a technical Sodom and Gomorrah.

In my late teens, I went through a period of wanting to be a diplomat for the State Department.  The prospect of traveling, learning languages, and being an actor in world history appealed to me.  My father, a former case officer in Vietnam, recommended joining the CIA instead.  As he put it to me (and as old Company hands had put it to him), diplomats only ever think they know what is going on in a given country.  It is the spies that really know.

The knowledgeableness -- and even competence -- of intelligence agencies have been called into question over the past few years with the inability to track down bin Laden and, before that, the inability to accurately assess Iraq's nuclear capabilities.  I was surprised to read recently in an article by John Le Carré for The New Yorker that, contrary to my father's impression, this may have long been the case.

Discussing his time as an insider in British intelligence, Le Carré writes about his disappointment with the discrepancy between what he had imagined it to be and what it turned out to actually be.  In terms reminiscent of the longings of many career professionals, he describes "fantasizing about a real British secret service, somewhere else, that did everything right that we either did wrong or didn't do at all."

As an IT consultant I encounter many technical experts, and am a bit of one myself in some rather abstruse areas.  A common frustration among these experts is that expertise does not always grant them authority, as one would expect in a meritorious modern corporate society.  Instead, contrarily, they find that corporate authority tends to confer expertise.  The managerial classes inside the corporations we work with are able to dictate technical directions not because they know about these technologies, but rather simply because they have the authority to do so.

In part this is simply how the system works.  Expertise and authority go together, but not in the ways one would expect.  In the corporate world, authority granted through expertise in one area, say managerial or financial expertise and a track record of success, grants additional and possibly unjustified acknowledgment of expertise in unrelated fields.

Another reason, however, must be due to the incommunicability of IT expertise.  The field is complicated and its practitioners are not generally known for their communication abilities.  Whereas the spooks of the intelligence world are not allowed to communicate their detailed knowledge to the layman, the IT professional is simply unable to.  IT professionals speak "geek talk," while business professionals speak corporate speak, and translators between these two dialects are few and far between.  Philosophically, however, such translations and transitions are possible, and the people who can do it make excellent careers for themselves.

What happens, however, when the whole notion of expertise is called into question.  As Stanley Rosen once said of Nietzsche, what happens when the esoteric becomes exoteric, and what we all know about our own failings and shortcomings as "experts" becomes public knowledge?

Such a thing seems to be happening now with the world economic crisis (I'm waiting for an expert to come along with a better moniker for this downward spiral we seem to all be going through, but for the moment "WEC" seems to be working).  The world economic crisis seems to have occurred because people who should have known better: bankers, traders, investors and economists, never put a stop to a problem with bad debt, bad credit and bubble markets of worldwide proportions.  As I understand it, all these people knew things weren't kosher but were hoping to take advantage of market distortions to make huge profits before bailing out at the last moment, but like the unfortunate fellow who raced James Dean in Rebel Without a Cause, they all failed to jump when they were supposed to.

Yet they were the experts.  As back up we have men like Henry Paulson at the Treasury to fix these messes, and he started out sounding authoritative about what needed to be done.  We needed $700 billion to fix the situation or at least to make it not so bad and the government had a plan, we were told, to do so.  However, the plan has mutated and meandered to the point that it now looks like it is being made up as we go along.  This in itself may not be such a bad thing, but is this meandering the sort of thing experts are supposed to do?

Recently the heads of the automotive industry came to Washington to ask for bailout money and, as we now all know, they didn't have a plan for how they planned to spend it.  Is that how experts act?

After the flood, the big discussion now seems to be whether we should try to preserve our laissez-faire system or try to improve it and correct it with more regulation.  The sages of Wall Street seem to actually like this solution, which is in itself an admission that they no longer see themselves as experts or, apparently, of even being capable of managing their own affairs.  They would prefer that another authority correct their own excesses for them, since they no longer trust themselves.

But if there are no experts any longer on Wall Street, where all they had to do was look after their own interests, can we really expect to find one in Washington that will look over all of our interests?  I don't mean to be a knee-jerk conservative on this matter, but does it make sense that when our clever people make it clear that they are not so clever or competent after all, we must look for someone that much more clever than all of them put together to fix things?  Can that level of expertise even exist?

And so I find myself fantasizing about a different America, indeed a different world, in which they get everything right that we either do wrong or don't do at all.

I will be presenting at GGMUG, the Greater Gwinnett Microsoft User Group, on October 9th.  My topic is building N-tier applications using WCF (the announcement from GGMUG says I'll be presenting on WPF, but I'm not going to let a consonant get in my way).

Of course all the buzz is around WCF and SOA architectures these days, but people actually still write traditionally architected applications, and WCF makes it soooo easy.

If you are in town and have a few hours to kill, please stop by.  The session starts at 6:30 at Gwinnett Technical College, with food and drinks provided by Magenic Technologies.

Methodology is one of those IT topics that generally make my eyes glaze over.  There is currently a hefty thread over on the altdotnet community rehashing the old debates about waterfall vs. agile vs. particular flavors of agile. The topic follows this well-worn pattern: waterfall, which dominated the application development life cycle for so many years, simply didn't work, so someone had to invent a lightweight methodology like XP to make up for its deficiencies.  But XP also didn't always work, so it was necessary to come up with other alternatives, like Scrum, Rational, etc., all encapsulated under the rubric "Agile". (Which agile methodology came first is a sub-genre of the which agile methodology should I use super-genre, by the way.)  Both Waterfall and the various flavors of Agile are contrasted against the most common software development methodology, "Cowboy Coding" or "Seat-of-the-pants" programming, which is essentially a lack of structure.  Due to the current common wisdom regarding agile, that one should mix-and-match various agile methodologies until one finds a religion one can love, there is some concern that this is not actually all that distinguishable from cowboy coding. 

For an interesting take on the matter, you should consult Steve Yegge's classic post, Good Agile, Bad Agile.

I have a friend who, in all other ways, is a well-grounded, rational human being in the engineering field, but when the topic of Druids comes up, almost always at his instigation, I feel compelled to find a reason to leave the room.  The elm, the ewe, the mistletoe, the silver sickle: these subjects in close constellation instill in me a sudden case of restless legs syndrome.

Not surprisingly, discussions concerning Methodology give me a similar tingly feeling in my toes.  This post in the altdotnet discussion caught my eye, however:

I also don't believe it is possible to do the kind of planning waterfall requires on any sufficiently large project. So usually what happens is that changes are made to the plan along the way as assumptions and understandings are changed along the way.

Rather than belittle waterfall methodology as inherently misguided, the author expresses the novel notion that it is simply too difficult to implement.  The fault in other words, dear Brutus, lies not in our stars, but in ourselves.

Rabbi Gershom Ben Judah, also known as the Light of the Exile, besides being a formidable scholar, is also notable for his prohibition of polygamy in the 10th century, a prohibition that applied to all Ashkenazy jews, and which was later adopted by Sephardis as well. The prohibition required particular care, since tradition establishes that David, Solomon, and Abraham all had multiple wives.  So why should it be that what was it good for the goose is not so for the gander?

Rabbi Gershom's exegesis in large part rests on this observation: we are not what our forefathers were.  David, Solomon, and Abraham were all great men, with the virtue required to maintain and manage  polygamous households.  However, as everyone knows, virtue tends to become diluted when it flows downhill.  The modern (even the 10th century modern) lacks the requisite wisdom to prevent natural jealousies between rival wives, the necessary stamina to care for all of his wives as they deserve, and the practical means to provide for them.  For the modern to attempt to live as did David, Solomon, or Abraham, would be disastrous personally, and inimical to good order generally.

What giants of virtue must have once walked the earth.  There was a time, it seems, when the various agile methodologies were non-existent and yet large software development projects were completed, all the same.  It is perhaps difficult for the modern software developer to even imagine such a thing, for in our benighted state, stories about waterfall methodology sending men to the moon seem fanciful and somewhat dodgy -- something accomplished perhaps during the mythical man month, but not in real time.

Yet it is so.  Much of modern software is built on the accomplishments of people who had nothing more than the waterfall method to work with, and where we are successful, with XP or Scrum or whatever our particular religion happens to be, it is because we stand on the shoulders of giants.

I find that I am not tempted, all the same.  I know my personal shortcomings, and I would no more try to implement a waterfall project than I would petition for a second wife.  I am not the man my forefathers were.

 

Song

Go and catch a falling star,
Get with child a mandrake root,
Tell me where all past years are,
Or who cleft the devil's foot,
Teach me to hear mermaids singing,
Or to keep off envy's stinging,
And find
What wind
Serves to advance an honest mind.

If thou be'st born to strange sights,
Things invisible to see,
Ride ten thousand days and nights,
Till age snow white hairs on thee,
Thou, when thou return'st, wilt tell me,
All strange wonders that befell thee,
And swear,
No where
Lives a woman true and fair.

If thou find'st one, let me know,
Such a pilgrimage were sweet;
Yet do not, I would not go,
Though at next door we might meet,
Though she were true, when you met her,
And last, till you write your letter,
Yet she
Will be
False, ere I come, to two, or three.

--John Donne

Why do software projects fail? is not a philosophical question in Descartes' sense, that is one that can be decomposed in order to arrive at a practical solution.  Rather, it is a contemplative problem in Aristotle's sense: one that can be looked at in many ways in order to reveal something about ourselves.

 

Software projects fail because we are weak.  We can make software projects better not by becoming stronger, but by minding our own weaknesses.  The truth is that software programming has made a lot of progress over the past twenty years.  It has not made it along the via positiva, however, through solutions such as OO, or Design Patterns, or Agile, or SOA, or a host of other white knight solutions that over time have turned out mostly to be hype.

 

Rather it has progressed through the via negativa, or by learning what not to do.  The via negativa was originally a mode of theological discourse, mystical in essence, which strived to understand God not in terms of what He is, but in terms of what He is not.  This mystical path serves well in pragmatic matters, also, and below I will outline some principles of the via negativa as applied to software development. 

 

I should include the caveat that I am not sure these principles have ever worked well for me, and that I continue to underestimate the scope of a task and the amount of time it will take to finish it.  On the positive side, I believe it all could have all been worse.

 

The Via Negativa of Software Development

 

1. Programming is neither an Art nor a Science

The thing I like best about Hunt and Thomas's book The Pragmatic Programmer is their attempt in the first chapter to analogize the act of programming to the Medieval journeyman tradition and the concept of craft.  I liked it so much, in fact, that I never bothered to read the rest of their book.  The point of thinking of programming as a craft is that we escape the trap of thinking of it in other ways.

 

Many programmers think of coding as an art, in the romantic sense.  Every project is new and requires a new solutions.  The solutions a programmer applies constitute a set of conceits that express the programmer's own uniqueness.  Rather than applying mundane and known solutions to a set of programming problems, the artist coder prefers to come up with solutions that will express his originality.

 

On the other side, some programmers think of coding as a science.  There is a set of best ways to accomplish any given task and their role is to apply that perfect solution.

 

Between these two is the notion of programming as craft.  There are a set of ways of doing things, such as retrieving data from a database or displaying them for data entry.  The craftsman's goal is to accomplish his tasks in the ways he knows how to do it, whether they are the best or not, with as little waste as possible.  The craftsman's motto is also Voltaire's: Le mieux est l'ennemi du bien.

 

2. Don't Invent when you can Steal

A corollary to the craftsman's motto is not to invent what you can steal.  One of the biggest mistakes that developers make is to assume that their problems are unique to them.  In fact, most problems in programming have been faced before, and developers are unusually generous about publishing their solutions on the Internet for others to use.  Good design should always involve, early in the process, using Google to find how others have solved your problems.  This is somewhat different from the Patterns frame-of-mind which assumes that there are common theoretical solutions to recurring problems.  What you really want to find are common implementations, specific to the language and platform you are using, to your programming needs.

 

This was a well-known and commonly applied rule in the early days of radio.  Comics would freely steal jokes from one another without attribution, and occasionally would complain about how many of their jokes were being used on other stations.  What the radio comics knew, and we need to relearn, is that the success of the punchline depends not on the setup, but on the delivery.

 

3. Smells are More Important than Patterns

Software changes too quickly for patterns to be useful.  By the time patterns are codified, they are already obsolete.  With experience, however, also comes a knowledge of what doesn't work, and it is rarely the case that something that hasn't worked in the past will somehow magically start working in the present.

 

A smell is a short-hand term for things you know will not work.  While Richard Feynman was known as a gifted physicist at Los Alamos during the Manhattan Project, his peculiar talent was in intuiting what not to do.  He would go from project to project and, without knowing all the details, be able to tell those involved wether they were on the right path or the wrong path.  Eventually, his intuition about such matters became something other physicists respected and relied upon.

 

Feynman had a natural gift for sniffing out bad smells, which he couldn't completely explain himself.  With experience, we all come to develop a good nose for smells, which manifest as a sense that something is wrong.  The greatest trick is to trust our respective noses and take smells into account, so that smells become identified as risks which deserve to be monitored.

 

Here are some common smells that emanate from doomed projects:

• Taking process shortcuts
• Too many meetings in which nothing is accomplished
• Custom Frameworks
• Hysterical laughter (oddly a common phenomenon when people start realizing there is something wrong with the project but are not willing to say so)
• Secrets between development roles
• No time to document
• No project plan
• No hard deadlines
• No criteria for the success of a project
• No time for testing
• Political fights between development roles (these are typically a symptom of a bad project, rather than a cause)
• Managers who say that everything is on track
• Managers who initially were setting themselves up to take all the credit are now positioning themselves to avoid all blame

 

4. Shame Drives Good Code

The most successful innovations in software development over the past twenty years have been shame based.  Pair-programming works because there is always a second set of eyes watching what we are doing.  It is difficult to take shortcuts or ignore standards when someone else is likely to call one on it almost immediately.

 

Code reviews are a more scattershot approach to the same problem.  Given that a code review can treat any piece of production code as a topic of analysis, it behooves the programmer to add comments, break up methods, and a host of other good coding practices in order to avoid having other developers point out obvious laziness. 

 

QA groups are the ultimate wielders of shame as a tool to drive good development practices.  QA brings obvious mistakes to light.  A developer who might try to slip in bad business logic without first verifying that it works, on the self-assurance that it should work, is less likely to so if he knows his private malfeasance might be brought to public light.  While QA is typically bad at catching problems with deep programming logic, they can instill a sense of shame in developers that will lead them to verify and thoroughly unit test their deep logic as they would test their shallow logic, knowing that others are watching. 

 

5. Manage Risk, Not Progress

All the points above are programmer-centric.  Manage risk, not progress is an essential rule for managers, project managers and business analyst.  Because programming tasks can be shifted around, it is common to put off difficult problems till the end, simply because one can.  This makes project plans, which measure all tasks with a common rule stick, notoriously bad at predicting the success level of a project at any given time.

 

Measuring risk is a better way to determine the success of a project.  To my thinking, identifying risk and determining whether risks have been overcome is the chief role of a good project manager.  If he spends the rest of his time surfing the Internet, I couldn't care less.  Unfortunately, many project managers insist on reading self-help books about leadership and interpret their role to be one of offering inspiration to others.  They often view their roles in this way to such a degree that they tend to refrain from tracking risk, which is always a downer.  And the best way to avoid tracking risk is to never identify it in the first place.

 

6. The Code Must Flow

Code must be treated as disposable.  It must be treated as a commodity.  It is a common feature of coding to treat every piece of code as special.  On the other hand, we know that it isn't true when we review our code months later.  What is truly gained in coding through a problem is not the physical code itself, but the knowledge of how to solve the problem. 

 

By constantly coding through every phase of a project, we gain knowledge of the problem domain.  By disposing of our code when we know it doesn't work, and starting over, we learn not to make fetishes of our code.

 

The second worst programming practice is when a prototype is turned into a real application.  This is a problem for developers.  It seems like it will save time to simply build on the same code that we started prototyping with, despite the fact that it fails to implement good practices or commenting or any of the other things we have come to expect from good code.

 

The worst programming practice is when management asks how long it will take to release a prototype, and demands the code be sent out as is.  There is no answer to this worst of all programming practices, for while nothing can straighten out the crooked timber of humanity, poor management can always warp it further.

In the Theatetus, Plato writes that 'philosophy begins in wonder'.  Here is Jowett's translation of the passage:

Soc: ...I believe that you follow me, Theaetetus; for I suspect that you have thought of these questions before now.

Theaet. Yes, Socrates, and I am amazed when I think of them; by the Gods I am! and I want to know what on earth they mean; and there are times when my head quite swims with the contemplation of them.

Soc. I see, my dear Theaetetus, that Theodorus had a true insight into your nature when he said that you were a philosopher, for wonder is the feeling of a philosopher, and philosophy begins in wonder. He was not a bad genealogist who said that Iris (the messenger of heaven) is the child of Thaumas (wonder).

In the Metaphysics, Aristotle continues the same theme (tr. W. D. Ross):

For it is owing to their wonder {ex archês men ta procheira tôn atopôn thaumasantes} that men both now begin and at first began to philosophize; they wondered originally at the obvious difficulties, then advanced little by little and stated difficulties about the greater matters, e.g. about the phenomena of the moon and those of the sun and of the stars, and about the genesis of the universe. And a man who is puzzled and wonders thinks himself ignorant (whence even the lover of myth is in a sense a lover of Wisdom, for the myth is composed of wonders); therefore since they philosophized in order to escape from ignorance, evidently they were pursuing science in order to know, and not for any utilitarian end.

This wonder tradition in philosophy has two principles. One is that wonder must lead to the articulation of questions, for without questions and dialectic, wonder never goes any further.  The second is that questioning must be non-utilitarian, and that its end must be contemplation, rather than the solution to a practical problem; in other words, questions must be open-ended in order to count as philosophical (i.e., pure scientific) problems.

Thus Aristotle continues, in Book II of the Metaphysics:

The investigation of the truth is in one way hard, in another easy. An indication of this is found in the fact that no one is able to attain the truth adequately, while, on the other hand, we do not collectively fail, but every one says something true about the nature of things, and while individually we contribute little or nothing to the truth, by the union of all a considerable amount is amassed. Therefore, since the truth seems to be like the proverbial door, which no one can fail to hit, in this respect it must be easy, but the fact that we can have a whole truth and not the particular part we aim at shows the difficulty of it.

Against this tradition, Descartes, an extremely practical man, argues in Articles 77 and 78 of Passions of the Soul (tr. Stephen H. Voss):

Furthermore, though it is only the dull and stupid who do not have any constitutional inclination toward Wonder {l'admiration}, this is not to say that those who have the most intelligence are always the most inclined to it.  For it is mainly those who, even though they have a good deal of common sense, still do not have a high opinion of their competence [who are most inclined toward wonder].

And though this passion seems to diminish with use, because the more one encounters rare things one wonders at, the more one routinely ceases wondering at them and comes to think that any that may be presented thereafter will be ordinary, nevertheless, when it is excessive and makes one fix one's attention solely upon the first image of presented objects without acquiring any other knowledge of them, it leaves behind a habit which disposes the soul to dwell in the same way upon all other presented objects, provided they appear the least bit new to it.  This is what prolongs the sickness of the blindly curious -- that is, those who investigate rarities only to wonder at them and not to understand them.  For they gradually become so given to wonder that things of no importance are no less capable of engaging them than those whose investigation is more useful.

Descartes found many ways to break with the Aristotelian tradition that had dominated Western thought for over a millennium, but none, I think, more profound than this dismissal of the wonder tradition.  In this brief passage, he places intelligence {l'esprit} above contemplation as the key trait of philosophizing.

A consequence of this is that the nature of philosophical questioning must also change.  In a Cartesian world, questions must have a practical goal.  Difficult problems can be broken down into their components, and if necessary those must be broken down into their components, until we arrive at a series of simple problems that can be solved easily.

Descartes' position is only strengthened by what is often called the scandal of philosophy: why, given all this time, has philosophy failed to answer the questions it originally set for itself?

• Does God exist? 
• Is there life after death? 
• Do we possess free will?
• What is happiness, and is it attainable?
• What is Justice?
• What is Knowledge?
• What is Virtue?

Another way to look at the scandal, however, is not as a problem of lacking answers to these questions, but rather as a problem of having an overabundance of answers.  Philosophy, over the centuries, has answered the question of God's existence with both a yes and a no.  There are five canonical proofs of God's existence, as well as a multitude of critical analyses of each of these proofs.  We are told that Occam's Razor, originally a tool of theological discourse, demands that we reject God's existence.  At the same time, we are told that Occam's Razor, the principle that simple answers are preferable to complex answers, itself depends on a rational universe for its justification; for the only thing that can guaranty that the universe is simple and comprehensible rather than Byzantine in its complexity, is God Himself.

The scandal of philosophy is itself based on a presupposition: that this overabundance of answers, and the lack of definitive answers, is contrary to the purpose of philosophical questioning.  Yet we know of other traditions in which the lack of answers is indeed a central goal of philosophical questioning.

Zen koans are riddles Zen masters give to their students to help them achieve enlightenment.  Students are expected to meditate on their koans for years, until the koan successfully works its effect on them, bringing them in an intuitive flash into the state of satori. 

• Does a dog have Buddha-nature?
• What is the sound of one hand clapping?
• What was your original face before you were born?
• If you meet the Buddha, kill him.

I dabble in the collecting of questions, and with regard to this habit, the observation Descartes makes above about the curious "who investigate rarities only to wonder at them and not to understand them" fits me well.  One of my favorite sets of questions comes from Robert Graves's The White Goddess, a book which, starting from an analysis of The Romance of Teliesin that makes Frazer's Golden Bough seem pedestrian by comparison, attempts to unravel the true purpose of poetry and, in the process, answers the following questions:

• Who cleft the Devil's foot?
• What song did the Sirens sing?
• What name did Achilles use when he hid from the Achaeans in the women's tent?
• When did the Fifty Danaids come with their sieves to Britain?
• What secret was woven into the Gordian Knot?
• Why did Jehovah create trees and grass before he created the Sun, Moon and stars?
• Where shall Wisdom be found?

Another set comes from Slavoj Zizek's Enjoy Your Symptom!, in which Zizek elucidates certain gnomic pronouncements of Jacques Lacan through an analysis of mostly 50's Hollywood movies:

• Why does a letter always arrive at its destination?
• Why is a woman a symptom of man?
• Why is every act a repetition?
• Why does the phallus appear?
• Why are there always two fathers?

Modern life provides its own imponderables:

• Paper or plastic?
• Hybrid or Civic?
• Diet or exercise?
• Should I invest in my 401K or pay down my college loans?
• Should I wait to get an HD TV?
• When shall I pull out of the stock market?

There are no definitive right or wrong answers to these questions.  Rather, how we approach these questions as well as how we respond to them contribute to shaping who we are.  In his short work, Existentialism and Human Emotions, Sartre tells an anecdote about a student who once asked him for advice.  The student wanted to leave home and join the French Resistance.  The reasons were clear to him. The Germans were illegitimate occupiers and it was the duty of every able-bodied Frenchman to fight against them.  At the same time, the student had a sickly mother who required his assistance, and leaving her would not only break her heart, but he might possibly never see her again.  To leave her would entail sacrificing his filial duties, while not to leave her would entail abandoning his moral duty.  To this student, caught in the grips of a mortal quandary,  Sartre offered the unexpected advice: choose!

...[I]n  creating the man that we want to be, there is not a single one of our acts which does not at the same time create an image of man as we think he ought to be.  To choose to be this or that is to affirm at the same time the value of what we choose, because we can never choose evil.  We always choose the good, and nothing can be good for us without being good for all.

But this isn't the whole truth.  There are also choices we make that appear arbitrary at the time, committed without any thought of 'man as he ought to be,' but which turn out to have irreversible consequences upon who we become.  In the film The Goalie's Anxiety at the Penalty Kick, Wim Wenders follows a goalie who is kicked off of his soccer team after failing to defend against a penalty kick that costs his team the game.  The goalie proceeds aimlessly through a series of pointless and reprehensible acts.  I once asked a soccer-playing friend if the circumstances of the penalty kick are as they were described in the movie, and he said yes.  Before the penalty kick, against a skilled opponent, the goalie has no idea which way the ball will go.  He stands in the middle between the two posts and must choose which in direction he will leap, without enough information to determine whether his choice is the right one or the wrong one.  The only thing he knows is that if he does not leap, he will be certain to fail.

All these theoretical questions, and the survey of the theory of questioning in general, are intended to provide the background necessary for answering the very practical question:  Why do software projects fail?

Fred Brooks's succinct answer to this is: software projects fail because software projects are very hard to do.  In other words, we are asking the wrong question.  A better way to phrase the problem is "Why are we still surprised when software projects fail?"

This question might be extended to other fields of endeavor:

• Why are term papers turned in late?
• Why do we fail to pay our bills on time?
• Why do we lie when we are asked over the phone, "Were you sleeping?"

In the discipline of software development, it is often found as one item in a larger list of software koans:

• Why do software projects fail?
• Why does adding additional developers to a project slow the project down?
• Why does planning extra time to complete a task result in no additional work being done?
• Why do developers always underestimate?
• Why are expectations always too high?
• Why does no one ever read documentation?
• Why do we write documentation that no one ever reads?
• Why is the first release of any code full of bugs?

Here we have an overabundance of questions that can all be answered in the same way.  Kant phrased the answer in this way:

Out of the crooked timber of humanity, no straight thing was ever made.

Aristotle phrases it thus in Metaphysics II:

Perhaps, too, as difficulties are of two kinds, the cause of the present difficulty is not in the facts but in us.

Interviewing has been on a my mind, of late, as my company is in the middle of doing quite a bit of hiring.  Technical interviews for software developers are typically an odd affair, performed by technicians who aren't quite sure of what they are doing upon unsuspecting job candidates who aren't quite sure of what they are in for.

Part of the difficulty is the gap between hiring managers, who are cognizant of the fact that they are not in position to evaluate the skills of a given candidate, and the in-house developers, who are unsure of what they are supposed to be looking for.  Is the goal of a technical interview to verify that the interviewee has the skills she claims to possess on her resume?  Is it to rate the candidate against some ideal notion of what a software developer ought to be?  Is it to connect with a developer on a personal level, thus assuring through a brief encounter that the candidate is someone one will want to work with for the next several years?  Or is it merely to pass the time, in the middle of more pressing work, in order to have a little sport and give job candidates a hard time?

It would, of course, help if the hiring manager were able to give detailed information about the kind of job that is being filled, the job level, perhaps the pay range -- but more often than not, all he has to work with is an authorization to hire "a developer", and he has been tasked with finding the best that can be got within limiting financial constraints.  So again, the onus is upon the developer-cum-interviewer to determine his own goals for this hiring adventure.

Imagine yourself as the technician who has suddenly been handed a copy of a resume and told that there is a candidate waiting in the meeting room.  As you approach the door of the meeting room, hanging slightly ajar, you consider what you will ask of him.  You gain a few more minutes to think this over as you shake hands with the candidate, exchange pleasantries, apologize for not having had time to review his resume and look blankly down at the sheet of buzzwords and dates on the table before you.

Had you more time to prepare in advance, you might have gone to sites such as Ayenda's blog, or techinterviews.com, and picked up some good questions to ask.  On the other hand, the value of these questions is debatable, as it may not be clear that these questions are necessarily a good indicator that the interviewee had actually been doing anything at his last job.  He may have been spending his time browsing these very same sites and preparing his answers by rote.  It is also not clear that understanding these high-level concepts will necessarily make the interviewee good in the role he will eventually be placed in, if hired. 

Is understanding how to compile a .NET application with a command line tool necessarily useful in every (or any) real world business development task?  Does knowing how to talk about the observer pattern make him a good candidate for work that does not really involve developing monumental code libraries?  On the other hand, such questions are perhaps a good gauge of the candidate's level of preparation for the interview, and can be as useful as checking the candidate's shoes for a good shine to determine how serious he is about the job and what level of commitment he has put into getting ready for it.  And someone who prepares well for an interview will, arguably, also prepare well for his daily job.

You might also have gone to Joel Spolsky's blog and read The Guerrilla Guide To Interviewing in order to discover that what you are looking for is someone who is smart and gets things done.  Which, come to think of it, is especially helpful if you are looking for superstar developers and have the money to pay them whatever they want.  With such a standard, you can easily distinguish between the people who make the cut and all the other maybe candidates.  On the other hand, in the real world, this may not be an option, and your objective may simply be to distinguish between the better maybe candidates and the less-good maybe candidates.  This task is made all the harder since you are interviewing someone who is already a bit nervous and, maybe, has not even been told, yet, what he will be doing in the job (look through computerjobs.com sometime to see how remarkably vague most job descriptions are) for which he is interviewing.

There are many guidelines available online giving advice on how to identify brilliant developers (but is this really such a difficult task?)  What there is a dearth of is information on how to identify merely good developers -- the kind that the rest of us work with on a daily basis and may even be ourselves.  Since this is the real purpose of 99.9% of all technical interviews, to find a merely good candidate, following online advice about how to find great candidates may not be particularly useful, and in fact may even be counter-productive, inspiring a sense of inferiority and persecution in a job candidate that is really undeserved and probably unfair.

Perhaps a better guideline for finding candidates can be found not in how we ought to conduct interviews in an ideal world (with unlimited budgets and unlimited expectations), but in how technical interviews are actually conducted in the real world.  Having done my share of interviewing, watching others interview, and occasionally being interviewed myself, it seems to me that in the wild, technical interviews can be broken down into three distinct categories.

Let me, then, impart my experience, so that you may find the interview technique most appropriate to your needs, if you are on that particular side of the table, or, conversely, so that you may better envision what you are in for, should you happen to be on the other side of the table.  There are three typical styles of technical interviewing which I like to call: 1) Jump Through My Hoops, 2) Guess What I'm Thinking, and 3) Knock This Chip Off My Shoulder.

 

Jump Through My Hoops

Jump Through My Hoops is, of course, a technique popularized by Microsoft and later adopted by companies such as Google.  In its classical form, it requires an interviewer to throw his Birkenstock shod feet over the interview table and fire away with questions that have nothing remotely to do with programming.  Here are a few examples from the archives.  The questions often involve such mundane objects as manhole covers, toothbrushes and car transmissions, but you should feel free to add to this bestiary more philosophical archetypes such as married bachelors, morning stars and evening stars, Cicero and Tully,  the author of Waverly, and other priceless gems of the analytic school.  The objective, of course, is not to hire a good car mechanic or sanitation worker, but rather to hire someone with the innate skills to be a good car mechanic or sanitation worker should his IT role ever require it.

Over the years, technical interviewers have expanded on the JTMH with tasks such as writing out classes with pencil and paper, answering technical trivia, designing relational databases on a whiteboard, and plotting out a UML diagram with crayons.  In general, the more accessories required to complete this type of interview, the better.

Some variations of JTMH rise to the level of Jump Through My Fiery Hoops.  One version I was involved with required calling the candidate the day before the job interview and telling him to write a complete software application to specification, which would then be picked apart by a team of architects at the interview itself.  It was a bit of overkill for an entry-level position, but we learned what we needed to out of it.  The most famous JTMFH is what Joel Spolsky calls The Impossible Question, which entails asking a question with no correct answer, and requires the interviewer to frown and shake his head whenever the candidate makes any attempt to answer the question.  This particular test is also sometimes called the Kobayashi Maru, and is purportedly a good indicator of how a candidate will perform under pressure.

 

Guess What I'm Thinking

Guess What I'm Thinking, or GWIT, is a more open ended interview technique.  It is often adopted by interviewers who find JTMH a bit too constricting.  The goal in GWIT is to get through an interview with the minimum amount of preparation possible.  It often takes the form, "I'm working on such-and-such a project and have run into such-and-such a problem.  How would you solve it?"  The technique is most effective when the job candidate is given very little information about either the purpose of the project or the nature of the problem.  This establishes for the interviewer a clear standard for a successful interview: if the candidate can solve in a few minutes a problem that the interviewer has been working on for weeks, then she obviously deserves the job.

A variation of GWIT which I have participated in requires showing a candidate a long printout and asking her, "What's wrong with this code?"  The trick is to give the candidate the impression that there are many right answers to this question, when in fact there is only one, the one the interviewer is thinking of.  As the candidate attempts to triangulate on the problem with hopeful answers such as "This code won't compile," "There is a bracket missing here," "There are no code comments," and "Is there a page missing?" the interviewer can sagely reply "No, that's not what I'm looking for," "That's not what I'm thinking of, "That's not what I'm thinking of, either," "Now you're really cold" and so on.

This particular test is purportedly a good indicator of how a candidate will perform under pressure.

 

Knock This Chip Off My Shoulder

KTCOMS is an interviewing style often adopted by interviewers who not only lack the time and desire to prepare for the interview, but do not in fact have any time for the interview itself.  As the job candidate, you start off in a position of wasting the interviewer's time, and must improve his opinion of you from there.

The interviewer is usually under a lot of pressure when he enters the interview room.  He has been working 80 hours a week to meet an impossible deadline his manager has set for him.  He is emotionally in a state of both intense technical competence over a narrow area, due to his life-less existence for the past few months, as well as great insecurity, as he has not been able to satisfy his management's demands. 

While this interview technique superficially resembles JTMFH, it is actually quite distinct in that, while JTMFH seeks to match the candidate to abstract notions about what a developer ought to know, KTCOMS is grounded in what the interviewer already knows.  His interview style is, consequently, nothing less that a Nietzschean struggle for self-affirmation.  The interviewee is put in the position of having to prove herself superior to the interviewer or else suffer the consequences.

Should you, as the interviewer, want to prepare for KTCOMS, the best thing to do is to start looking up answers to obscure problems that you have encountered in your recent project, and which no normal developer would ever encounter.  These types of questions, along with an attitude that the job candidate should obviously already know the answers, is sure to fluster the interviewee. 

As the interviewee, your only goal is to submit to the superiority of the interviewer.  "Lie down" as soon as possible.  Should you feel any umbrage, or desire to actually compete with the interviewer on his own turf, you must crush this instinct.  Once you have submitted to the interviewer (in the wild, dogs generally accomplish this by lying down on the floor with their necks exposed, and the alpha male accepts the submissive gesture by laying its paw upon the submissive animal) he will do one of two things;  either he will accept your acquiescence, or he will continue to savage you mercilessly until someone comes in to pull him away.

This particular test is purportedly a good indicator of how a candidate will perform under pressure.

 

Conclusion

I hope you have found this survey of common interviewing techniques helpful.  While I have presented them as distinct styles of interviewing, this should certainly not discourage you from mixing-and-matching them as needed for your particular interview scenario.  The schematism I presented is not intended as prescriptive advice, but merely as a taxonomy of what is already to be found in most IT environments, from which you may draw as you require.  You may, in fact, already be practicing some of these techniques without even realizing it.

 

Download SAPISophiaDemo.zip - 2,867.5 KB

 

Following on the tail of the project I have been working on for the past month, a chatterbox (also called a chatbot) with speech recognition and text-to-speech functionality, I came across the following excerpted article in The Economist, available here if you happen to be a subscriber, and here if you are not:

 

 

Jabberwacky is a slightly different beast than the AIML infrastructure I used in my project.  Jabberwacky is a heuristics based technology, whereas AIML is a design-based one that requires somebody to actually anticipate user interactions and try to script them.

All the same, it is a pleasant experience to find that one is serendipidously au courant, when one's intent was to be merely affably retro.

I have been busy in my basement constructing a robot with which I can have conversations and play games.  Except that the robot is more of a program, and I didn't build the whole thing up from scratch, but instead cobbled together pieces that other people have created.  I took an Eliza-style interpreter written by Nicholas H.Tollervey (this is the conversation part) along with some scripted dialogs by Dr. Richard S. Wallace and threw it together with a Z-machine program written by Jason Follas, which allows my bot to play old Infocom games like Zork and The Hitchhiker's Guide to the Galaxy.  I then wrapped these up in a simple workflow and added some new Vista\.NET 3.0 speech recognition and speech synthesis code so the robot can understand me.

I wrote an article about it for CodeProject, a very nice resource that allows developers from around the world to share their code and network.  The site requires registration to download code however, so if you want to play with the demo or look at the source code, you can also download them from this site.

Mr. Tollervey has a succint article about the relationship between chatterboxes and John Searle's Chinese Box problem, which obviates me from responsibility for discussing the same.

Instead, I'll just add some quick instructions:

 

The application is made up of a text output screen, a text entry field, and a default enter button. The initial look and feel is that of an IBX XT theme (the first computer I ever played on). This can be changed using voice commands, which I will cover later. There are three menus initially available. The File menu allows the user to save a log of the conversation as a text file. The Select Voice menu allows the user to select from any of the synthetic voices installed on her machine. Vista initially comes with "Anna". Windows XP comes with "Sam". Other XP voices are available depending on which versions of Office have been installed over the lifetime of that particular instance of the OS. If the user is running Vista, then the Speech menu will allow him to toggle speech synthesis, dictation, and the context-free grammars. By doing so, the user will have the ability to speak to the application, as well as have the application speak back to him. If the user is running XP, then only speech synthesis is available, since some of the features provided by .NET 3.0 and consumed by this application do not work on XP.

The appearance menu will let you change the look and feel of the text screen.  I've also added some pre-made themes at the bottom of the appearnce menu.  If, after chatting with SophiaBot for a while, you want to play a game, just type or say "Play game."  SophiaBot will present you with a list of the games available (you can add more, actually, simply by dropping additional game files you find on the internet into the Program Files\Imaginative Universal\SophiaBot\Game Data\DATA folder (Jason's Z-Machine implementation plays games that use version 3 and below of the game engine.  I'm looking (rather lazily) into how to support later versions.  You can go here to download more Zork-type games.  During a game, type or say "Quit" to end your session. "Save" and "Restore" keep track of your current position in the game, so you can come back later and pick up where you left off.

Speech recognition in Vista has two modes: dictation and context-free recognition. Dictation uses context, that is, an analysis of preceding words and words following a given target of speech recognition, in order to determine what word was intended by the speaker. Context-free speech recognition, by way of contrast, uses exact matches and some simple patterns in order to determine if certain words or phrases have been uttered. This makes context-free recognition particularly suited to command and control scenarios, while dictation is particularly suited to situations where we are simply attempting to translate the user's utterances into text.

You should begin by trying to start up a conversation with Sophia using the textbox, just to see how it works, as well as her limitations as a conversationalist. Sophia uses certain tricks to appear more lifelike. She throws out random typos, for one thing. She also is a bit slower than a computer should really be. This is because one of the things that distinguish computers from people is the way they process information -- computers do it quickly, and people do it at a more leisurely pace. By typing slowly, Sophia helps the user maintain his suspension of disbelief. Finally, if a text-to-speech engine is installed on your computer, Sophia reads along as she types out her responses. I'm not certain why this is effective, but it is how computer terminals are shown to communicate in the movies, and it seems to work well here, also. I will go over how this illusion is created below.

In Command\AIML\Game Lexicon mode, the application generates several grammar rules that help direct speech recognition toward certain expected results. Be forewarned: initially loading the AIML grammars takes about two minutes, and occurs in the background. You can continue to touch type conversations with Sophia until the speech recognition engine has finished loading the grammars and speech recognition is available. Using the command grammar, the user can make the computer do the following things: LIST COLORS, LIST GAMES, LIST FONTS, CHANGE FONT TO..., CHANGE FONT COLOR TO..., CHANGE BACKGROUND COLOR TO.... Besides the IBM XT color scheme, a black papyrus font on a linen background also looks very nice. To see a complete list of keywords used by the text-adventure game you have chosen, say "LIST GAME KEYWORDS." When the game is initially selected, a new set of rules is created based on different two word combinations of the keywords recognized by the game, in order to help speech recognition by narrowing down the total number of phrases it must look for.

In dictation mode, the underlying speech engine simply converts your speech into words and has the core SophiaBot code process it in the same manner that it processes text that is typed in. Dictation mode is sometimes better than context-free mode for non-game speech recognition, depending on how well the speech recognition engine installed on your OS has been trained to understand your speech patterns. Context-free mode is typically better for game mode. Command and control only works in context-free mode.

Voice command technology, as exemplified in Part II, is probably the most useful and most easy to implement aspect of the Speech Recognition functionality provided by Vista.  In a few days of work, any current application can be enabled to use it, and the potential for streamlining workflow and making it more efficient is truly breathtaking.  The cool factor, of course, is also very high.

Having grown up watching Star Trek reruns, however, I can't help but feel that the dictation functionality is much more interesting than the voice command functionality.  Computers are meant to be talked to and told what to do, as in that venerable TV series, not cajoled into doing tricks for us based on finger motions over a typewriter.  My long-term goal is to be able to code by talking into my IDE in order to build UML diagrams and then, at a word, turn that into an application.  What a brave new world that will be.  Toward that end, the SR managed API provides the DictationGrammar class.

Whereas the Grammar class works as a gatekeeper, restricting the phrases that get through to the speech recognized handler down to a select set of rules, the DictateGrammar class, by default, kicks out the jams and lets all phrases through to the recognized handler.

In order to make Speechpad a dictation application, we will add the default DicatateGrammar object to the list of grammars used by our speech recognition engine.  We will also add a toggle menu item to turn dictation on and off.  Finally, we will alter the SpeechToAction() method in order to insert any phrases that are not voice commands into the current Speechpad document as text.  Create an local instance of DictateGrammar for our Main form, and then instantiate it in the Main constructor.  Your code should look like this:

	#region Local Members
		
        private SpeechSynthesizer synthesizer = null;
        private string selectedVoice = string.Empty;
        private SpeechRecognitionEngine recognizer = null;
        private DictationGrammar dictationGrammar = null;
        
        #endregion
        
        public Main()
        {
            InitializeComponent();
            synthesizer = new SpeechSynthesizer();
            LoadSelectVoiceMenu();
            recognizer = new SpeechRecognitionEngine();
            InitializeSpeechRecognitionEngine();
            dictationGrammar = new DictationGrammar();
        }
        

Create a new menu item under the Speech menu and label it "Take Dictation".  Name it takeDictationMenuItem for convenience. Add a handler for the click event of the new menu item, and stub out TurnDictationOn() and TurnDictationOff() methods.  TurnDictationOn() works by loading the local dictationGrammar object into the speech recognition engine. It also needs to turn speech recognition on if it is currently off, since dictation will not work if the speech recognition engine is disabled. TurnDictationOff() simply removes the local dictationGrammar object from the speech recognition engine's list of grammars.

		
        private void takeDictationMenuItem_Click(object sender, EventArgs e)
        {
            if (this.takeDictationMenuItem.Checked)
            {
                TurnDictationOff();
            }
            else
            {
                TurnDictationOn();
            }
        }

        private void TurnDictationOn()
        {
            if (!speechRecognitionMenuItem.Checked)
            {
                TurnSpeechRecognitionOn();
            }
            recognizer.LoadGrammar(dictationGrammar);
            takeDictationMenuItem.Checked = true;
        }

        private void TurnDictationOff()
        {
            if (dictationGrammar != null)
            {
                recognizer.UnloadGrammar(dictationGrammar);
            }
            takeDictationMenuItem.Checked = false;
        }
        

For an extra touch of elegance, alter the TurnSpeechRecognitionOff() method by adding a line of code to turndictation off when speech recognition is disabled:

        TurnDictationOff();

Finally, we need to update the SpeechToAction() method so it will insert any text that is not a voice command into the current Speechpad document.  Use the default statement of the switch control block to call the InsertText() method of the current document.

        
        private void SpeechToAction(string text)
        {
            TextDocument document = ActiveMdiChild as TextDocument;
            if (document != null)
            {
                DetermineText(text);
                switch (text)
                {
                    case "cut":
                        document.Cut();
                        break;
                    case "copy":
                        document.Copy();
                        break;
                    case "paste":
                        document.Paste();
                        break;
                    case "delete":
                        document.Delete();
                        break;
                    default:
                        document.InsertText(text);
                        break;
                }
            }
        }

        

With that, we complete the speech recognition functionality for Speechpad. Now try it out. Open a new Speechpad document and type "Hello World."  Turn on speech recognition.  Select "Hello" and say delete.  Turn on dictation.  Say brave new.

This tutorial has demonstrated the essential code required to use speech synthesis, voice commands, and dictation in your .Net 2.0 Vista applications.  It can serve as the basis for building speech recognition tools that take advantage of default as well as custom grammar rules to build adanced application interfaces.  Besides the strange compatibility issues between Vista and Visual Studio, at the moment the greatest hurdle to using the Vista managed speech recognition API is the remarkable dearth of documentation and samples.  This tutorial is intended to help alleviate that problem by providing a hands on introduction to this fascinating technology.

This is simply a side by side pastiche of the history of Extreme Programming and the history of Methodism.  It is less a commentary or argument than simply an experiment to see if I can format this correctly in HTML.  The history of XP is drawn from Wikipedia.  The history of Methodism is drawn from John Wesley's A Short History of Methodism.

 

A difficult aspect of software programming is that it is always changing.  This is no doubt true in other fields, also, but there is no tenure system in software development.  Whereas in academe, it is quite plausible to reach a certain point in your discipline and then kick the ladder out behind you, as Richard Rorty was at one point accused of doing, this isn't so in technology.  In technology, it is the young who set the pace, and the old who must keep up.

The rapid changes in technology, with which the weary developer must constantly attempt to stay current, can be broken down into two types: there are advances in tools and advances in methodologies.  While there is always a certain amount of fashion determining which tools get used -- for instance which is the better language, VB.Net or C#? --, for the most part development tools are judged based upon their effectiveness. This is not necessarily true concerning the methodologies of software development.  Which is odd since one would suppose that the whole point of a method is that it is a way of guaranteeing certain results -- use method A, and B (fame, fortune, happiness) will follow.

There is even something of a backlash against methodism (or, more specifically, certain kinds of methodism) being led, interestingly enough, by tool builders.  For instance, Rocky Lhotka, the creator of the CSLA framework says:

Joel Spolsky, the early Microsoft Excel Product Manager and software entrepreneur, has also entered the fray a few times.  Most recently, an blog post by Steve Yegge (a developer at Google) set the technology community on fire:

The general tenor of these skeptical treatments is that Extreme Programming (and its umbrella methodology, Agile) is at best a put-on, and at worst a bit of a cult.  What is lacking in these analyses, however, is an explication of why programming methodologies like Extreme Programming are so appealing.  Software development is a complex endeavor, and its practitioners are always left with a sense that they are being left behind.  Each tool that comes along in order to make development easier always ends up making it actually more difficult and error prone (though also more powerful).  The general trend of software devlopment has consistently been not less complexity, but greater complexity.  This leads to an indemic sense of insecurity among developers, as well as a sense that standing still is tantamount to falling behind.  Developers are, of course, generally well compensated for this burden (unlike, for instance, untenured academics who suffer from the same constraints) so there is no sense in feeling sorry for them, but it should be clear, given this, why there is so much appeal in the notion that there is a secret method which, if they follow it correctly, will grant them admission into the kingdom and relieve them of their anxieties and doubts.

One of the strangest aspects of these methodologies is the notion that methods need evangelists, yet this is what proponents of these concepts self-consciously call themselves.  There are Extreme Programming evangelists, SCRUM evangelists, Rational evangelists, and so on who write books and tour the country giving multimedia presentations, for a price, about why you should be using their methodology and how it will transform you and your software projects. 

So are software methodologies the secular equivalent of evangelical revival meetings?  It would depend, I suppose, on whether the purpose of these methodologies is to make money or to save souls.  Let us hope it is the former, and that lots of people are simply making lots of money by advocating the use of these methodologies.

"But the greatest thing by far is to have a mastery of metaphor. This alone cannot be imparted by another; it is the mark of genius, for to make good metaphors implies an eye for resemblances."  -- Aristotle, The Poetics

 

It is a trivial observation that software programmers use a lot of metaphors.  All professions are obliged to invoke metaphors in one way or another, but in software programming I think the program is so extensive that we are not even aware of the fact that creating metaphors is our primary job.  We are only ever immediately aware of the metaphorical character of our profession when we use similes to explain technical matters to our managers.  Such-and-such technology will improve our revenue stream because it is like a new and more reliable conduit for information. It can be combined with sundry-and-other technology, which acts as a locked box for this information.

When speaking with technical colleagues, in turn, we use a different set of metaphors when explaining unfamiliar technology.  We say that "Ajax is like Flash", "Flash is like instant messaging", "instant messaging is like talking to services in a SOA", "SOA is like mainframe programming", b is like c, c is like d, d is like e, and so on.  Every technology is explained in reference to another technology, which in turn is just a metaphor for something else.  But does explicating one metaphor by simply referencing another metaphor really explain anything?  Is there a final link in the chain that ultimately cascades meaning back up the referential chain?

I have occasionally seen these referential chains referred to as a prison house of language, though perhaps a house of mirrors would be more appropriate in this case.  We work with very complex concepts, and the only way to communicate them is through metaphors, even when, as in a fun house, the only points of reference we have for explaining these concepts are other concepts we find reflected in a reflection of a reflection.  This metaphorical character of our occupation, however, is typically hidden from us because we use a different set of terms to describe what we do.  We don't typically speak about metaphors in our programming talk; instead we speak of abstractions.

Not only are abstractions explained in terms of other abstractions, but they are also typically abstractions for other abstractions.  In Joel Spolsky's explication of "Leaky Abstractions" (which is, yes, also a metaphor) we discover that TCP is really an abstraction thrown over IP.  But IP is itself an abstraction of other technologies, which in turn may in themselves also involve further abstractions.  At what point do the abstractions actually end?  Is it when we get to the assembler language level?  Is it when we get to machine language?  Do we finally hit bottom when we reach the point of talking about electricity and circuit boards?

Again, I will posit (in a handwaving and unsubstantiated manner) that the main occupation of a software programmer is working with metaphors.  Taking this as a starting point, it is strange that in the many articles and discussion threads addressing the question, what makes a good programmer?, poetry is never brought up. Overlooking Aristotle's professed opinion that a gift for metaphor is something that cannot be taught, we might assume that if it is indeed something that can be cultivated, a likely starting point is through the reading and writing of poetry.  It would be a pleasant change if in looking over technical resumes, we also starting looking for signs that prospective employees to BigTech.com also were published in poetry journals or participated in local poetry readings.

But perhaps that is asking for too much.  The only other profession in which metaphors are applied extensively is in politics.  Just as metaphors are called abstractions in programming, in politics they are called "framing".  Behind the notion of framing in politics is the assumption that certain metaphors are simply more naturally appealing than others.  The proper metaphor will motivate one's audiences emotions either toward one's platform or against one's opponents platform.  The mastery of metaphor in politics, consequently, entails being able to associate one's own position with the most emotively powerful metaphor into which one can fit one's position. 

One interesting aspect of the endeavor of framing is that a political metaphor is required to be fitting, that is the metaphor one uses to explain a given position or argument must be appropriate to that argument, and an absence of fitting will generally detract from the force of the metaphor.  That there is this question of fittingness provides two ways to characterize political metaphors.  There are metaphors that seem to naturally apply to a given circumstance, and hence garner for the person who comes up with such metaphors a reputation for vision and articulateness.  Then there are metaphors that are so powerful that it does not matter so much that the circumstance to which it is applied is not so fitting, in which case the person who comes up with such metaphors gains a reputation as a scheming framer.

Determining which is which, of course, generally depends on where one is standing, and in either case we can say that both are masters of metaphor in Aristotle's sense.  However, because there is so much question about the integrity of metaphors in politics, it is tempting to eschew the whole thing.  As wonderful as metaphors are, politics tends to make everything dirty in the end.

Which leaves software programming as the only place where metaphors can be studied and applied in a disinterested manner.  In programming, the main purpose of our abstractions is not to move people's emotions, but rather to clarify concepts, spread comprehension and make things work better.  It is the natural home not only for mathematicians, but for poets.

I am not the first to suggest it, but I will add my voice to those that want to claim that Giulio Camillo built the precursor of the modern personal computer in the 16th century.  Claiming that anyone invented anything is always a precarious venture, and it can be instructive to question the motives of such attempts.  For instance, trying to determine whether Newton or Leibniz invented calculus is a simple question of who most deserves credit for this remarkable achievement. 

Sometimes the question of firsts is intended to reveal something that we did not know before, such as Harold Bloom's suggestion that Shakespeare invented the idea of personality as we know it.  In making the claim, Bloom at the same time makes us aware of the possibility that personality is not in fact something innate, but something created.  Edmund Husserl turns this notion on its head a bit with his reference in his writings to the Thales of Geometry.  Geometry, unlike the notion of personality, cannot be so easily reduced to an invention, since it is eidetic in nature.  It is always true, whether anyone understands geometry or not.  And so there is a certain irony in holding Thales to be the originator of Geometry since Geometry is a science that was not and could not have been invented as such.  Similarly, each of us, when we discover the truths of geometry for ourselves, becomes in a way a new Thales of Geometry, having made the same observations and realizations for which Thales receives credit. 

Sometimes the recognition of firstness is a way of initiating people into a secret society.  Such, it struck me, was the case when I read as a teenager from Stephen J. Gould that Darwin was not the first person to discover the evolutionary process, but that it was in fact another naturalist named Alfred Russel Wallace, and suddenly a centuries long conspiracy to steal credit from the truly deserving Wallace was revealed to me -- or so it had seemed at the time. 

Origins play a strange role in etymological considerations, and when we read Aristotle's etymological ruminations, there is certainly a sense that the first meaning of a word will somehow provide the key to understanding the concepts signified by the word.  There is a similar intuition at work in the discusions of 'natural man' to be found in the political writings of Hobbes, Locke and Rousseau.  For each, the character of the natural man determines the nature of the state, and consequently how we are to understand it best.  For Hobbes, famously, the life of this kind of man is rather unpleasant.  For Locke, the natural man is typified by his rationality.  For Rousseau, by his freedom.  In each case, the character of the 'natural man' serves as a sort of gravitational center for understanding man and his works at any time. I have often wondered whether the discussions of the state of the natural man were intended as a scientific deduction or rather merely as a metaphor for each of these great political philosophers.  I lean toward the latter opinion, in which case another way to understand firsts is not as an attempt to achieve historical accuracy, but rather an attempt to find the proper metaphor for something modern.

So who invented the computer?  Was it Charles Babbage with his Difference Engine in the 19th century, or Alan Turing in the 20th with his template for the Universal Machine?  Or was it Ada Lovelace, as some have suggested, the daughter of Lord Byron and collaborator with Charles Babbage who possibly did all the work while Babbage receives all the credit?

My question is a simpler one: who invented the personal computer, Steve Jobs or Giulio Camillo.  I award the laurel to the Camillo, who was known in his own time as the Divine Camillo because of the remarkable nature of his invention.  And in doing so, of course, I merely am attempting to define what the personal computer really is -- the gravitational center that is the role of the personal computer in our lives.

Giulio Camillo spent long years working on his Memory Theater, a miniaturized Vitruvian theater still big enough to walk into, basically a box, that would provide the person who stood before it the gift most prized by Renaissance thinkers: the eloquence of Cicero.  The theater itself was arranged with images and figures from greek and roman mythology.  Throughout it were Christian references intermixed with Hermetic and Kabalistic symbols.  In small boxes beneath various statues inside the theater fragments and adaptations of Cicero's writings could be pulled out and examined.  Through the proper physical arrangment of the fantastic, the mythological, the philosophical and the occult, Camillo sought to provide a way for anyone who stepped before his theater be able to discourse on any subject no less fluently and eloquently than Cicero himself.

Eloquence in the 16th century was understood as not only the ability of the lawyer or statesman to speak persuasively, but also the ability to evoke beautiful and accurate metaphors, the knack for delighting an audience, the ability to instruct, and mastery of diverse subjects that could be brought forth from the memory in order to enlighten one's listeners.  Already in Camillo's time, mass production of books was coming into its own and creating a transformation of culture.  Along with it, the ancient arts of memory and of eloquence (by way of analogy we might call it literacy, today), whose paragon was recognized to be Cicero, was in its decline.  Thus Camillo came along at the end of this long tradition of eloquence to invent a box that would capture all that was best of the old world that was quickly disappearing.  He created, in effect, an artificial memory that anyone could use, simply by stepping before it, to invigorate himself with the accumulated eloquence of all previous generations.

And this is how I think of the personal computer.  It is a box, occult in nature, that provides us with an artificial memory to make us better than we are, better than nature made us.  Nature distributes her gifts randomly, while the personal computer corrects that inherent injustice.  The only limitation to the personal computer, as I see it, is that it can only be a repository for all the knowledge humanity has already acquired.  It cannot generate anything new, as such.  It is a library and not a university.

Which is where the internet comes in.  The personal computer, once it is attached to the world wide web, becomes invigorated by the chaos and serendipity that is the internet.  Not only do we have the dangerous chaos of viruses and trojan horses, but also the positive chaos of online discussions, the putting on of masks and mixing with the online personas of others, the random following of links across the internet that ultimately leads us to make new connections between disparate concepts in ways that seem natural and inevitable.

This leads me to the final connection I want to make in my overburdened analogy.  Just as the personal computer is not merely a box, but also a doorway to the internet, so Giulio Camillo's Theater of Memory was tied to a Neoplatonic worldview in which the idols of the theater, if arranged properly and fittingly, could draw down the influences of the intelligences, divine beings known variously as the planets (Mars, Venus, etc.), the Sephiroth, or the Archangels.  By standing before Camillo's box, the spectator was immediately plugged into these forces, the consequences of which are difficult to assess.  There is danger, but also much wonder, to be found on the internet.