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 …