According to tradition, the tritone was called the Devil's Chord or the Diabolis in Musica, a sound so dissonant and so puissant it was believed to be capable of raising the Lord of Hell himself.  For this reason, in it's irrationality, the Roman Catholic Church banned the Devil's Triad, on pain of excommunication.  Today, of course, bands such as Metallica and Black Sabbath  use the tritone on a regular basis with no adverse effects.

The irrational is a powerful force that may be harnessed, dear reader, by those willing play on the fringes of reality.  Three magical phrases, irrational yet powerful and well known to the practitioners of the dark arts, can be invoked by anyone who desires to kill a technical project they dislike.  Today, dear reader, I will teach you these three phrases.

But first, a word about motivations.  According to Nietzsche, the driving force behind modern man's desire for power is, tout court, resentment.  We all resent the guy who comes in the middle of a software project and starts making suggestions about how to improve it.  As the new guy, in turn, we resent the old and crusty way things are done, as if the way things are done is the only way.  Resentment, in other words, is the mother of invention when it comes to technology, and we each, in our own way, embrace it as we strive toward a new tomorrow.  In a perfect world, we may all act as the angels, but in the real world, we may occasionally be forced to make deals ex inferis.  Which is not to recommend what I am about to teach you.  I ask you, moreover, to use these techniques judiciously.  One should not call upon the powers of the underworld lightly.  But should you find yourself in a situation where rational discourse is no longer possible, and rhetorical brute force is required, then these phrases may be of use to you.

1. It's too complex.  It's not maintainable.

This is a wonderful phrase.  It is universally applicable since any useful piece of code will end up being complex, and one can never overemphasize the incompetence of one's peers when discussing maintainability.  And with luminaries like Joel Spolsky and Jeff Atwood backing you, how can you go wrong?  If you want to kill any technology -- WCF, WPF, .NET Remoting, 3-tier architecture -- just invoke this magic phrase and it will wither away.

2. It's not scalable.

Amazingly enough, this diabolical mantra can be called upon without any evidence.  No one will ever turn around and ask you to justify your claim -- be it with a load tester or anything.  Simply say these magic words and your enemies will cower before you.  Anything cool -- like reflection, say -- will cause a certain amount of performance degradation.  This is normal of course.  In software there are always tradeoffs, and exchanging performance for other advantages such as robustness and decoupling are the norm.  Unless, of course, you make trade offs impossible.  The magic phrase "It's not scalable" instantly makes any trade off seem impossible.  It's very well, after all, to lose 5 milliseconds on a transaction, but what happens when you have a gazillion transactions?!!!  That's 5 milli-gazillion units of time that you have cost the company, and time is money!  That's 5 milli-gazillion dollars you've cost the company!   By golly, this solution is not scalable!

3. It will push us beyond our deadline.

"The solution you have provided is all well and good, and I mean neither to question your integrity nor your intelligence, but given the fact that it is not maintainable and not scalable, I fear that trying to implement it will push us beyond our deadline."  I've never worked on a project that wasn't "time sensitive" and rarely on one that wasn't needed "yesterday".  There's no better way to kill an idea, even when it comes out of  the mouth of someone who refuses to say definitively when a project will in fact be completed, than to say that it will push us past our deadline.  I've seen this used when determining which architecture to use.  I've even seen it used in determining which textbox control to use.  If you ever find yourself in a position where you have an idea that is competing with someone else's idea, you can quickly sweep your adversary's idea aside by invoking this occult phrase: It will push us beyond our deadline.

Why are these magic phrases never tested?  Why are they impervious to standards of verifiability traditionally expected in other fields?  The reason is simple.  Software development is always seen, from the outside, as a kind of magic, and any successful project has at its heart some secret sauce, some magic code, that makes it all possible.

This is the magic unicorn principle.  At the heart of any successful application stands a magic unicorn.  You feed it data, no matter how disorganized or moldy, and it comes out the other end a rainbow.  Data in.  Rainbows out.  It's beautiful in its simplicity.

In my next post, I will demonstrate how to build a DIRO magic assembly.  Stay tuned ...

The problem with conjuring tricks is that they lose practically all their glamour once you find out how they are done.  It's very cool to see David Blaine walk down the street, do a few passes over his hand, and resurrect a fly which proceeds to flee.  It's rather disappointing to do a google search and discover that in order to prepare for this trick, the first requirement is that you freeze a fly.

My trick is to make an autocomplete extender from the Ajax Control Toolkit call a WCF service instead of an asmx service.  For this recipe, I assume that you are already familiar with the autocomplete extender, and that you are using Visual Studio 2008.  I warn you in advance -- my trick disappoints.  It is so trivially easy that, once the technique spreads, it is very unlikely to impress your colleagues at work, much less get you a date with a supermodel.

Science is all about making proposals that can be tested (especially after Karl Popper's formulation of the Falsifiability Criterion), and then undergoing the experience of having that proposal rejected.  This is the essence of any successful process -- not that it eliminates errors altogether, but rather that it is able to make corrections despite these errors so that the target need never shift.

Professor Alain Connes recently gave his opinion of Xin-Jing Li's proof for the Riemann Hypothesis -- a proof which relies in part on Professor Connes' work ...

Nancy Davolio was a fictitious employee in the Microsoft Access 97 Northwind sample database. Many office workers became smitten with her furtive smile and stylish hair, and while she continued to exist as an employee in later releases of the Northwind database, her employee photo changed, leading many to suspect that something untoward had happened to the real Nancy. As most people know, "Nancy Davolio" is an anagram for "A Navy Cod Loin" ...

Ajax, the fleet son of Oileus, commanded the Locrians. He was not so great, nor nearly so great, as Ajax the son of Telamon. He was a little man, and his breastplate was made of linen, but in use of the spear he excelled all the Hellenes and the Achaeans. --The Iliad

Ajax son of Oileus is traditionally called Ajax the Lesser, while Ajax Telamon's son is Ajax the Greater.  The Trojan War  is often portrayed as a battle between the national heroes of two great armies, Hector on one side, and Achilles on the other.  What makes the arraying of the sides peculiar is that, in fact, the Achaeans have two heroes that can defeat the war chief of the Trojans.  Both Achilles and Ajax the Greater are superior warriors to Hector.  This feature was actually a giveaway to many classicists back in 1959 that the newly released western Warlock was based on The Iliad.

Two years ago Microsoft began a campaign to carve out a niche in the Ajax world...