A Guest Editorial by Phil Factor...
It's in my nature to try to think of new business opportunities in IT.
One of my enduring fancies is to start up a company that specialises in the euthanasia of IT developments. There are plenty of people who wreck them by sheer fat-headedness, but I mean deliberate mercy-killing. The idea came to me from a friend who had a dearly-loved old pet dog who was beginning to suffer. He couldn't bring himself to take the dog to the vet to have him put down, and just happened to remark that he wished that there was a company that would undertake pet-assassinations, so that he somehow wouldn't feel directly responsible for being his dumb chum's nemesis.
I tried to imagine shooting an aged pet with a high-caliber rifle, as it staggered arthritically into the garden to answer the call of nature, but it wasn't really my scene. However, the equivalent procedure for an ailing IT project…now that had merit!
I could immediately think of any number of projects that had struggled painfully on, long after the original business requirement was a distant memory, and the possibility of success a misty dream. Such projects cause much heartache, and often-ruinous expense. Unfortunately, very few companies take the responsibility for publicly calling a halt to a project in time to prevent this; they simply lack the courage to look a developer or project manager squarely in the eye and tell him that his beloved project is toast.
However, what if the company that wanted to do a 'wet job' on one of their IT projects could make a discreet phone call to "Phil Factor Enterprises Inc"? All unwanted projects disposed of with minimum fuss and complete discretion. Database projects a specialty!
The fact is that there are many ways to "tweak" parts of a SQL Server database that would result in baffling behaviour, and soon have the developers running for the hills. I tremble to think of the number of ways I have accidentally brought a SQL Server Database to its knees: and most of these could be used maliciously and undetectably.
I won't tell you any of these sabotage techniques, just in case the wrong people read this editorial. Here, though, is a simple example that has been so well-known for a couple of years that I'm not teaching the villains anything new. Just create one or more triggers and insert this code:
IF convert(int,RAND() * 100 + 1)=20
BEGIN
declare @Cause varchar(22)
select @Cause =case when rand()>0.5 then 'lock' else 'communication buffer' end
RAISERROR( 'Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.', 13, 52, @@SPID, 22, @cause )
ROLLBACK TRANSACTION
RETURN
END
The result is apparently random deadlocks for around one in every hundred transactions involving the table. It is surprising how few people notice that the message number is wrong, (should be 1205), or who use trace flag 1204 to gather more information.
One dreams of course, but I can't help wondering if there is some technique, along these lines, that would cause such a crisis as to afford a business the excuse to send a tormented project toward the light in a painless way, breathe a sigh of relief, and move on.
Phil Factor.
