Tag: Software

What kind of consultant are you?

James Ashley7 Comments

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

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

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.

 

TOP GUN

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 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

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

Neo can re-program reality.

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

 

terminator3

The Chick from Terminator 3

Pros: She’s smokin’ hot.

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

 

macguyver

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

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.

 

ben

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.

 

baldwin

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

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

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.

 

jump_to_conclusions_guy

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

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.

 

lumburgh

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.

William James and the Squirrel

James Ashley13 Comments

  squirrel

 

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.

On Pragmatism: some excerpts

James Ashley1 Comment

wjames

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 Lees and Scum of Bygone Men

James Ashley4 Comments

 

chinese_book

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

Promiscuity and Software: The Thirty-one Percent Solution

James Ashley2 Comments

 kiss

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.

Expertise and Authority

James Ashley2 Comments

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.

Presenting on WCF in October

James Ashley

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.

Waterfall and Polygamy

James Ashley1 Comment

polygamy

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.

Why is the timber crooked?

James Ashley1 Comment

Isaiah Berlin

 

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 (II)?

James Ashley

steichen

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.