Over the past week my family and I have been playing with an early Christmas present, an XBOX game called Rock Band.  This game one-ups the other popular rock simulation franchise, Guitar Hero, by allowing the player to perform on guitar, drums or with a mic.  A sort of guitar hero meets karaoke, it even allows different players to work together in forming a rock band either over the Internet or in their living room, side-by-side.

I have adopted the guitar as my own instrument for acquiring fame.  I have already mastered Don't Fear the Reaper (no cowbell, unfortunately), Wanted Dead or Alive, Mississippi Queen and Blitzkrieg Bop, at medium difficulty, and am currently rehearsing Suffragette City, which has a wicked A-X-Y riff (XBOX control buttons, naturally, not notes) that I cannot seem to get the hang of.

The game is wonderful, though as I play through I am flabbergasted by the number of songs I do not recognize.  Who are Vagiant, or Anarchy Club, or Crooked X?  There are other groups I know by name, like Weezer, Radiohead, and Foo Fighters, but until now I couldn't have named a song by any of them.   My knowledge of popular music seems to have ended sometime in the late eighties, and there is a decade and a half lacuna following that which I am loathe to fill.  Added to this the great number of metal anthems in this game combined with my ignorance of the Bon Jovi catalogue and the Metallica repertoire (though I do know -- who wouldn't -- Rush's Tom Sawyer and Black Sabbath's Paranoid),  and you may get a sense of the cultural irrelevance that washes over me as each new playlist is thrown onto my screen.

Worse, I believe I threw out my back during the extra points phase of Nine Inch Nails' The Hand That Feeds, and now rest supine, forbidden to play until my back heals or eventually snaps back into place.  How do aging rockers do it?  Keith Richards apparently has fresh blood transfused into his system every few years, but I believe his case is anomalous. 

Playing at being a rock star does have that element of grasping at one's lost youth to it.  Like the elixir imbibed by Richards, rock rhythm and tonal inflections are absorbed by the air-guitarist and, for a brief time, he undergoes a spiritual transmutation -- one that must be accomplished in privacy, of course, lest reality, or perchance an unfortunately placed mirror, dispel the glamour. 

Much of the current literature -- often found in blogs, of course -- discusses video games and virtual worlds as a sort of escapism.  The notion is that the unfulfilled middle-manager may find an emotional outlet for his work-induced frustrations in virtual games such as World of Warcraft, where everyone and anyone has the opportunity to be a hero.

I am not sure that this quite captures the phenomenon, however.  With Rock Band, the goal is not so much to escape one's reality but rather to participate in a different one -- more of a pull than a push, so to speak.  Plotinus, though in a different context, spoke of it as a hypostatic union; a union between oneself and a more perfect version of oneself; something that has the character of fulfilling one's nature rather than erasing it.

Such is my feeling when playing air-guitar on the XBOX.  I don't want to be someone else, but instead simply want to release an aspect of myself that requires lowering the bar a bit, through technology, and closing the gap between myself and the gods of rock and roll.  Surely this is the origin of all technology since Nimrod's tower, brought down by Jehovah for its impertinence.  Technology lifts us up, giving us health and the promise of immortality through medicine, cleverness through information technology, courage through online role-playing, and happiness through pharmacology.  Technology removes our frailties, leaving us as we were meant to be before the fall: young and immortal.

Speaking of growing old, I attended a Bob Dylan concert a few months ago.  Bob has been going through a bit of a revival, his U.S. tour coinciding with a documentary by Martin Scorsese and even a feature length biopic.  I have not been able to find an adequate way to write about the event, which I and my companions walked out of.  To say that Dylan couldn't sing seems to be missing the point, since this charge has always been leveled against him.  And to say that I did not like the new style he was playing also makes me sound like those who criticized Bob for going electric back in the day.

I might draw the contrast between Bob and Elvis Costello, who opened for him.  Elvis played several songs solo, both old and new, only changing guitars on occasion to fit the piece.  He was the Elvis I imagined, comfortable on stage, able to work the audience, singing in his off-key way to perfection.  He was the archetype of the solo college musician, fitting complex lyrics into a structured form meant to invoke interlaced feelings of sympathy and alienation -- the alienation of the artist -- in his audience.  Like a great beast, the audience responded to his coaxing, and he guided us through a peculiar journey and then deposited us gently when his set was over.

According to Jung, archetypes recur across cultures, and we seek them out, attempting to fill the recesses established in our minds.  Most of all we seek heroes, not because we seek to be heroes ourselves, necessarily, but because we have an inchoate sense that there must always be heroes.  Shakespeare provided heroes, sometimes twisted, sometimes broken, but heroes nonetheless, on the stage.  The modern rock star transforms himself to fulfill this role established for him.  The form required for the hero changes over time, and changes with context; Dylan was always able to adapt to these changing roles.  He served as a cipher, reflecting the image that people required of him.

The Scorsese documentary, built around a ten hour interview with Dylan, portrays a man who sees none of the depth in his own lyrics that others impute to them.  Perhaps he is simply being playful.  He discusses a radio interview in which the host asks Dylan whether -- actually, insists that -- A Hard Rain's a-Gonna Fall is about nuclear ash and the madness of nuclear proliferation, to which Dylan responds that the song is about rain, which is sometimes heavy, you know. 

Again and again, however, Dylan was able to capture the spirit of his times, several times, and people found in his lyrics answers to their questions and anxieties.  My favorite Dylan album is Desire, which is a combination of electric protest songs and wild fantasies, all within a cowboy motif.  I can't say what questions he answers for me in this, but I do know that I return to it again and again, and it puts me in a happy place.

According to Giambattista Vico, the 18th century Neapolitan philologist, the secret of metaphor is that it is not based on similarity, but rather on identity.  The secret of the hero is not that he makes himself resemble the classic hero.  He becomes that hero, transforming himself as needed, internally, until identity is achieved.  "The true war chief ... is the Godfrey that Torquato Tasso imagines; and all the chiefs who do not conform throughout to Godfrey are not true chiefs of war" as Vico said.

Dylan accomplished something similar, adopting the argot of protest singers like Pete Seeger when this was required of him.  As the times changed, he transformed himself again into the rebellious Bob, with dark glasses and an attitude, indifferent to the complaints about his going electric and "selling out," when in fact his ear was simply better attuned than that of those around him.  The Desire period marked him as a reclusive genius, when that was the thing to be.  In the 80's and 90's, he identified himself with the Christian revival, while his music turned bluesy in a time when we wanted heroes whose rough voices where inhabited by old wisdom and hard-earned experience.

The new Dylan (which is your favorite Dylan?) doesn't speak to me, however.  He has a sort of be-bop band in conservative zoot-suits accompanying him, and the music matches the look.  The music is pleasant enough, punctuated by Bob's gravelly voice hammering out quick phrases like "dondenktwysanizalri" or "juzlikawama."  But what it means, and who Bob Dylan represents, is unclear to me.  I hold out the possibility that he is simply ahead of the curve once again -- but what sort of culture requires a hero who is mostly pleasant and barely comprehensible?  Is this the zeitgeist of the 00's?

Like my back, my plastic XBOX Stratocaster has also given out.  After only a few hours of playing, the strummer is now mushy, and I am unable to get through the rapid 12 note riffs that seem to infest all the metal songs currently on my playlist like little roaches.  I have gone online and found a fix that requires me to remove the back of the guitar (there are 20 odd screws, and I am grateful for the gift of a Christmas past: a power drill with bit attachments) and than reset a tension bar inside the guitar mechanism, but this seems to only work for about five hours before the strummer becomes mushy again.  Apparently there is a known problem with the early Rock Band Stratocasters, and Activision is allowing people to send their bad guitars in for a replacement.  Since I am currently in a state of rock star disability, I think I may take advantage of this, and with luck by the time my guitar is healed, my back will be, too.

Every family has its peculiar Christmas traditions.  My family's holiday traditions are strongly influenced by a linguistic dispute back in A.D. 1054, one consequence of which is that we celebrate Christmas on January 7th, 13 days after almost everyone else we know does so.  This has its virtues and its vices.  One of the vices is that we clean up on holiday shopping, since we are afforded an extra 13 days to pick up last minute presents, which gets us well into the time zone of post-holiday sales.  Another is that we always wait until a period somewhere between December 23rd and December 26th to buy our Christmas tree.  We typically are able to pick up our trees for a song, and last year were even able to get a tall frosty spruce without even singing.

This history of vice has finally caught up with us, for this year, as we stalked forlornly through the suburbs of Atlanta, no Christmas trees were to be found.  Lacking foresight or preparation, we have found ourselves in the midst of a cut-tree shortage.  And what is a belated Christmas without a cut-tree shedding in the living room?

We are now in the position of pondering the unthinkable.  Should we purchase an artificial tree this year (currently fifty-percent off at Target)?  The thought fills us with a certain degree of inexplicable horror.  Perhaps this is owing to an uncanny wariness about the prospects of surrendering to technology, in some way.  While not tree-huggers, as such, we have a fondness for natural beauty, and there are few things so beautiful as a tree pruned over a year to produce the correct aesthetic form, then cut down, transported, and eventually deposited in one's living room where it is affectionately adorned with trinkets and lighting.

Another potential source for the uneasiness my wife and I are experiencing is an association of these ersatz arboreals with memories of our childhoods in the late 70's and early 80's, which are festooned with cigarette smoke, various kinds of loaf for dinner, checkered suits, polyester shirts and, of course, artificial trees.  Is this the kind of life we want for our own children?

In the end, we have opted to get a three-foot, bright pink, pre-lit artificial tree.  Our thinking is that this tree will not offend so greatly if it knows its place and does not put forward pretensions of being real.

The linguistic ambiguity alluded to above has led to other traditions.  For instance, in Appalachia there are still people who cleave to the custom that on the midnight before January 6th, animals participate in a miracle in which they all hold concourse.  Briefly granted the opportunity to speak, all creatures great and small can be heard praying quietly and, one would imagine, discussing the events of the past year.  The significance of January 6th comes from the fact that the Church of England was late to adopt the Gregorian calendar, which changed the way leap years are calculated, and consequently so was America late.  Thus at the time that the Appalachian Mountains were first settled by English emigrants, the discrepancy between the Gregorian calendar and the Julian calendar was about 12 days (the gap, as mentioned above, has grown to 13 days in recent years).  The mystery of the talking animals revolves around a holiday that was once celebrated on January 6th , but is celebrated no more -- that is, Christmas.

According to this site, there is a similar tradition in Italy, itself.  On the day of the Epiphany, which commemorates the day the three magi brought gifts to the baby Jesus, the animals speak.

Italians believe that animals can talk on the night of Epiphany so owners feed them well. Fountains and rivers in Calabria run with olive oil and wine and everything turns briefly into something to eat: the walls into ricotta, the bedposts into sausages, and the sheets into lasagna.

The Epiphany is celebrated in Rome on January 6th of the Gregorian calendar.  It is possible, however, that even in Italy, older traditions have persisted under a different guise, and that the traditions of Old Christmas (as it is called in Appalachia) have simply refused to migrate 12 days back into December, and are now celebrated under a new name.  Such is the way that linguistic ambiguities give rise to ambiguities in custom, and ambiguities in custom give rise to anxiety over what to display in one's living room, and when.

As translated by Lady Charlotte Guest, excerpted from Robert Graves's The White Goddess: A Historical Grammar of Poetic Myth:

Discover what it is:

The strong creature from before the Flood

Without flesh, without bone,

Without vein, without blood,

Without head, without feet ...

In field, in forest...

Without hand, without foot.

It is also as wide

As the surface of the earth,

And it was not born,

Nor was it seen ...

 

[Answer: Ventus]

 

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.