A tip for managers: never alienate your DBAs. If you do, it is liable to lead to painful consequences. I speak from experience. Having suffered one of those occasional "reverses in career fortune", I wound up taking an appointment as a Team Leader/DBA for the IT support team of a German startup Telecommunications company.

I was intently staring at my screen one afternoon, as DBAs often do, when Jorgen, one of the senior managers, strode up to my desk. He was a rising star in the company due to the huge uptake of his new Italian coupon-based phone service. This was actually one project for which we weren't providing database support; Jorgen had recently sent an email tirade to the IT director stating that he was dispensing with the services of Central IT because we were too slow and hidebound. He was relying instead on 'his own dynamic staff'.

As far as Jorgen was concerned, our job was simply to supply, on request, management reports for the board detailing the stupendous success of his project.

"Is the report on my Italian phone service ready yet?" he snapped, with his usual level of tact.

"Good afternoon, Jorgen" I chirped, tearing my eyes reluctantly from the screen. "I trust that all is well with you. Unfortunately we're still working on the reports and I don't see them being ready until the end of the week."

"I'm meeting the CEO tomorrow afternoon and I must have it then. You promised it to me yesterday."

"Not so. You asked when I thought it would be ready. I told you I thought it would be ready yesterday. I was wrong in thinking it would be ready".

He should have asked me why I'd been wrong. He didn't.

"If I don't get it before the meeting on Thursday, there will be someone else in your shoes by Friday!"

The sentence echoed around the open-office area. I was supposed to be cowed into submission. Instead I laughed. "Sorry, but that's impossible"

"And why is that?" he said, coloring up. All eyes in the office were upon us.

"Because I'm wearing sandals"

He flounced out of the room. For a moment I savored the comic absurdity of the company putting so much faith in an idiot savant whose entire cerebral energy was focused on making money and, incidentally, enemies.

It is easy to come to believe that a DBA's many working hours spent staring into screens was merely a ruse designed to infuriate senior managers. In fact, in this case, before Jorgen had rudely interrupted me, I had been intensively following the evil activities of 'The Porker'.

The Porker, named evidently for his girth and disgusting eating habits, wasn't alone in trying to defraud large sums of money from telecoms companies. In those days, plenty of people were at it. The denationalization of the state-held phone companies had induced a rash of startups, like ours, staffed by people completely inexperienced in the wicked world of telephone fraud.

Jorgen had experienced a meteoric career in the denationalized telecoms companies. He had hypnotized our CEO into believing that he was uniquely qualified to spearhead the introduction of profitable new telephone products into the market. He could, he explained, succeed where the the old hidebound state-owned companies could merely fluster, because he had experience, energy, vision and confidence.

The Porker suffered no such self-delusion. He was experienced in telephone fraud. From his rooms in Manchester, he operated an extraordinarily ingenious operation that probed the weaknesses of all the new services. The scam was simple. The Porker, and his colleagues, set up a range of premium-rate services, each one using a newly-introduced premium-rate phone number. He then rang them via all the new telephone companies. If they charged him correctly, he moved on, having lost little. However, if a company failed to spot that it was a premium-rate number, he would immediately bombard his own premium-rate number with automated calls via that service provider. He would then get the payment for the call to his premium-rate number from his own provider, who would then bill the hapless telecoms company who routed the call to them. All he would have ‘invested’ for each call would have been a charge for the local rate. For every pound he spent, he would get a fifty-fold return.

There were many such scams, from the crude to the breathtakingly subtle, but The Porker's scam was typical. I often used to meet with fellow Telecomms DBAs, in a pub off Holborn that served extremely good pints of Youngs bitter, to discuss the latest activities of The Porker and his ilk.

As a team, we did all we could to ensure that our tariff tables were kept up-to-date and that customers were correctly billed. If it was a 'prepaid' service, then we ensured that the deduction was correct. However, it is an imperfect world, and occasionally, a fraudster such as the Porker would probe our defenses and find a weakness. In order to spot fraud in any business system, your detection system must look for the flurry of unusual activity by which the fraudster inevitably gives himself away. You'll never be able to guess beforehand all the potential avenues for fraud. All you can do is to spot the signs of such activity and puzzle out what they're up to. The DBA becomes like a carnivorous beast, all senses honed at spotting the rats. His senses are his queries, and his database tools. Our team had become very adept at producing queries that were sensitive enough, and unobtrusive enough, to catch the scams before we experienced heavy financial loss. We'd then react quickly to correct the tariff and slam the door shut on the likes of The Porker.

I was just one in a long line of DBAs that Jorgen had alienated. I was also the last, as it turned out. Through underestimating the forensic skills required of his IT support, he was uniquely vulnerable – and foolish. I settled back to writing the report on his Italian coupon service. A management report is one of the most frightening things a DBA can be responsible for. It has to be right. If you get a sales report wrong, it can lead to people being unfairly sacked or rewarded. If you get a profit or loss figure wrong, your management can commit huge resources to the wrong part of the business, and starve the real revenue-earners. I could see that there was something wrong with Jorgen's report, which is why I couldn't let it out. Jorgen's rudeness had merely served to supercharge my natural obstinacy.

The team combed through the raw data obsessively. When we spotted the problem, it was obvious and frightening. Jorgen's prepaid coupon service was losing us millions. The Tariff tables hadn't been updated, and the rats were crawling all over it. Coupons were being bought all over Italy, and being used to phone premium-rate numbers that we were mis-charging at standard rates. What looked like a brilliant and fast-expanding service was actually a feeding frenzy for the fraudsters. As soon as the whole horror was apparent, we laid it out before the IT director. He gave a low whistle and we immediately had a long conference call with the CEO. The following day we followed a plan. Jorgen, as expected, stormed up to my desk early in the morning.

"Where is my f***ing report?"

"Jorgen, how good to see you again. We're almost finished and we will deliver the report at the board meeting. I've cleared this with the IT Director and CEO "

"I told you I needed it before the meeting you ****". I raised an eyebrow: I'd never found myself likened to anyone's external genitalia before.

"I can appreciate your point of view, and I'm sorry I can't comply. These reports have to be rigorously cross-checked." His powers of expression ran out and he stormed off.

At the allotted time, I picked up ten copies of my report and popped upstairs to the board-room, where the meeting was already in progress. Jorgen was in full flow with a PowerPoint slide onscreen that showed the splendid growth in users of his Italian coupon service. I popped a copy of the report in front of every board member and sat on a chair next to the IT director.

When Jorgen had finished his presentation, the CEO turned to me with slight conspiratorial smile. 'Phil will now deliver the latest report on the new service, from the perspective of Central IT'

I stood up and told the board that, while the user figures for Jorgen's new service were indeed impressive, it had in fact lost the company a total of 5.6Million pounds sterling. This loss was directly attributable to a failure to add provision for proper fraud detection, brought about by his reckless refusal to use the services of central IT. After running through the figures, I sat down with a smile. Are all DBAs subjected to this sort of stressful activity, I wondered?

Jorgen was struck dumb. He sat there, puce in the face, staring ahead and sweating profusely. After a strangled cry, he suddenly erupted.

"That **** Phil Factor" he yelled, gesticulating wildly at me "He was smiling as he told you all that. That ignorant old b*stard wants me to fail! He was actually f***ing smiling!"

He had started to flex his biceps in a slightly alarming manner, so I nodded in an amiable way to the assembled board members and made a strategic exit.

On the Friday morning, I ambled into the office, sat down at my desk and took a long look down at my sandals. The feet in them were, reassuringly, my own. Shortly afterwards, I saw old Hans, the Facilities man, clearing out the content of Jorgen's desk and office, and unceremoniously dumping them into a cardboard box. The IT director later told me that Jorgen had tried every trick he knew to extricate himself, but had been encouraged by the unanimous board to spend a lot more time with his family. His departure caused barely a ripple of controversy; the telecoms industry has always been adept at burying its dead without disturbing its shareholders with all the gory details. No: it is never a good idea to alienate your DBAs.

When you make your house secure, you might want to do the obvious things such as putting good locks on the doors, and fasteners on the windows, but you are still interested on peeping through the curtains to watch for suspicious activity in the street. If people in balaclavas are carrying ladders and eyeing up the side of the house, or checking sight-lines, you’d want to know about it, surely.

Why take a different attitude when you put a website out there, particularly if it is a trading site with lots of confidential information? Wouldn’t you want to see what the villains are up to? A couple of years ago, I did just that. I felt like the little pig that had the house of brick. Although I was confident that I’d done enough to prevent the big bad wolf from blowing the site over, I wanted to know if he was eyeing up the chimney with a view to a sneaky entrance, especially if I could light a fire when he’s descending.

It was a fascinating and salutary experience. I was not aware of the extent of the activity that bombards a site to try to break it. It is a constant stream.

Some attacks are so simple, yet seem to be still worthwhile for the hacker.  Surely there aren't sites around still with this sort of vulnerability?  Just as an example, there was a continuous stream of 404s (returning a 404 error to the requester to tell them the file was not found), resulting from people trying to find the location of the admin site.  Hmm. Up to no good here. The combinations were endless. Responding to 404s is dumb, as it allows an automaton to go through a very long list; login.asp, login.php, index.asp, admin.php, maint.aspx, and so on until they get a successful request. As an experiment I made a lot of completely bogus admin pages to react to these sorts of requests. It caused a temporary rush of excitement to some east European somewhere. Here, I discovered, is one of the few ways that the long-suffering site-maintainer can fight back, and laugh like a drain as a human being attempts to hack into your bogus site-admin console. There is a delicious pleasure from constructing a completely bogus database, using SQL Data Generator, and watching the hackers break in, but be careful, as you don't want to provoke a retaliatory DOS attack. The payback is that you get to see the whole process of an attack.

I had great fun seeing the ingenuity of these attempts to log in as the administrator of my dummy site admin screen. Mostly, they use a shared script, probably a Perl script, though there are plenty of applications that will do a brute-force attack. There is no shortage of places on the internet that you can download these tools. You don't have to be clever to use them, just to think them up in the first place. Although a few were completely unintelligible to me, most  are simple.

This is the way they do it. They get the Admin login screen. They check the form, and see what the variables are, just by looking at the <form> block. They see if it is a POST or a GET. When they know how to send login data to the database they are away. They rely on a very elementary mistake. It is anticipating that user input is either incorrectly filtered for string literal escape characters such as '', or user input that has not been checked for correctness. It relies on SQL statements being constructed on the fly, and executed,  rather than parameterized.

The hacker determines, from the FORM block, the name of the script file, ASPX or PHP, perhaps, to log in to the site. Imagine that the parameters represent user ID and password. The <FORM> block will tell the hacker all he/she needs to know.

The hacker passes any UserID he wants, let’s use the example ‘DAVE’, and passes, as the password the string ‘’’ or 1=1 --  (there are around fifty combinations of Magic strings, which are variations on this.) This will sometimes get him logged in as administrator. Game over.

Even today, there is a chance that the ASP file will not check to see if there are single quotes in the password. It will just take the GET or POST variable and stuff it into a SQL query, hoping it will look like this....
SELECT USER_Identity FROM MyUsers WHERE userid='DAVE' AND password='secret'
…and will expect to return a non-zero recordset if the userid and password were correct. Instead, the query will look like this!
SELECT USER_Identity FROM MyUsers WHERE USER='DAVE' AND password='''' OR 1=1 --'

Our password value, which is one of the many ‘Magic Strings’ …
''' OR 1=1 --
    … has had delimiters added and the resulting code had returned every row. Try it.

--just to demonstrate the technique
--we build a bogus list of users and their passwords
CREATE TABLE MyUsers (User_Identity INT IDENTITY(1,1),
                       UserID VARCHAR(20),
                       Password VARCHAR(30))

INSERT INTO MyUsers(UserID, Password)
       SELECT 'Dave', 'voluble12'
INSERT INTO MyUsers(UserID, Password)        
       SELECT 'Tony', 'cockeyed3546'
INSERT INTO MyUsers(UserID, Password)        
       SELECT 'Robyn', 'workinghard408354'
INSERT INTO MyUsers(UserID, Password)        
   SELECT 'Bob', 'MyPasswordIsSecure2396845'
--This is the SQL Statement the programmer wanted to construct
SELECT USER_Identity FROM MyUsers WHERE userID='dave' AND password='voluble12'
--this is the string that the hacker likes to inject
SELECT USER_Identity FROM MyUsers WHERE USER='DAVE' AND password='''' OR 1=1 --'
GO
--although the 'dynamic SQL crimes are generally committed in ASP, here is
--a stored procedure that commits the crime.
ALTER PROCEDURE spLogin (@userID VARCHAR(80), @Password VARCHAR(80))
AS
EXECUTE ('Select USER_Identity from MyUsers where userID='''
           +@UserID
           +''' and password='''+@Password+'''')
GO
--innocent procedure call
EXECUTE spLogin 'dave', 'voluble12'
--U BIN HAKKED!!!
EXECUTE spLogin 'THE HAKKER', ''''''' or 1=1 --'

Now, you wouldn’t believe that anyone is dumb enough to keep an exploit like this open would you? The rookie programmer scoops up the name of the userID, and the password and does no sanity checks. He/She then constructs the SQL on the fly rather than using parameters or, better, calling stored procedures. He doesn't look at the contents of the result that is handed back to him, even to see how many rows there are.

Notice that if getting the admin login to your website isn’t enough for you, you can always do more extreme things such as delete the user table

EXECUTE spLogin 'THE DESTROYER', ''''''' drop table MyUsers --'
--Or look for backup files with a view to FTPing them to you
EXECUTE spLogin 'THE CURIOUS', ''''''' execute xp_cmdshell ''dir c:\windows'' --'

This is just the start, of course. You don’t have to be able to access the Admin screen to get the information from a database. As long as the programmer has forgotten to parameterize his queries, forgotten to check for escape characters, or has failed to check for the validity of the input, in just one of the scripts that call the database, then your database is at the mercy of the hacker.

The hacker can use a technique such as blind SQL injection or inference SQL injection. This essentially does a binary chop to read strings character-by-character so as to get from the database a whole realm of interesting information.  All that the hacker needs is an indication of when a query returns rows and when it doesn’t.  Time is on his side, as the website probably has no alerts for unusual activity. (a binary chop for character string causes a spike)

Some of the easiest hacks have been possible because the result of a query is always rendered on the browser. It is so tempting to create a single generic routine for rendering all data returned from the database as an HTML table, or list.

Of course, if the database users are set up properly, none of this is possible as the login from the website only has access to the Interface stored procedures, and you don’t use dynamic SQL in these.  You have to assume that the hacker is somehow going to be able to pick up the login credentials from the site, and you must plan accordingly. I use the extra precaution of a time-limited, and revokeable,  authorization key issued from the database. You can then relax as you study the amazing complexity of the attempts to get at your data. When I say ‘relax’ I’m only referring to ‘as relaxed as the third little pig whilst the big bad fox paces around the brick house, huffing and puffing’. You can’t predict in advance what the hacker will try. I always create a log that stores all accesses to the interface, along with the parameters passed. It really takes no extra time to do this. I read the weblogs into the database as well, to check for unusual spikes of activity. It’s always best to know what attacks are being made to your websites.

 

Tea drinking is important to developing software. It matters how you drink it, as well as how you prepare the tea.

It was a very long time ago, whilst working in a development team with a well-known computer company in Japan that I first realized there was more to drinking tea than dumping a typhoo teabag into a mug. One day, we’d reached that point where we were all completely jaded, when someone suggested going to see a Geisha for chakai. I had no idea what to expect and I was slightly apprehensive as I didn’t know the Japanese for ‘Excuse me Madam, but I’d rather keep my clothes on if you don’t mind’. We piled off into a bus and ended up in a beautiful wooden house where an elderly Japanese geisha, dressed in exquisite traditional kimono, entertained us to tea. We sat cross-legged around a table as she acted as hostess with both skill and dignity, entertaining us with a stream of jokes which had all the Japanese speakers convulsed in laughter. Even I couldn’t help giggling, though she could have been reading the telephone directory for all I knew. It worked like a charm. We piled back to work in a completely changed mood. I was amazed and delighted; and discovered that it was standard practice to ‘clear the brain’ in this way when things got stressed and out-of-proportion.

For Britain, the ceremony is quite different, but just as important. It is usually known as ‘cha’, the Chinese name, taken from army slang. First, the teapot; this must be brown earthenware, and has always been known as ‘Brown Betty’ for some reason. Brown Betty’s shape has been refined over hundreds of years. It is never dribblesome. (There is a book called ‘The Dribblesome Teapot’ by Norman Hunter, purely about a ‘Brown Betty’ that dribbles), It is brown because that color conserves the heat best. The Tea is of great importance. I favor a high-quality Assam, full-bodied, black as sin, unblended. Just to describe it make me tremble with excitement. A Sri Lanka Kanoy can be wonderful, producing a luscious bright-golden infusion. Darjeeling is excellent, with its rich, fruity taste. For variety, I’d always include Keemun or Oolong. Of course, on a hot day, a Celon tea is wonderful, served as Ice tea. People who claim they don’t like tea have probably drunk only disgusting reject leaves sent by puzzled producers in India over to the Midlands of England where it is mistakenly considered a delicacy.

I have a rather unconventional liking for Gunpowder tea, rolled in pellets, and unfermented. This Chinese green tea can be sipped for hours without the caffeine effect becoming unpleasant. In London, you will always find me in Soho, in an excellent Chinese restaurant where they happily bring you endless Brown Bettys full of piping hot Gunpowder tea.

I’m very much on the liberal wing as far as the preparation of tea goes. As I have previously pointed out in a blog, the art is to extract the caffeine without too much tannin; whilst conserving the aroma and flavor. The aroma relies on very volatile essential oils. You make a mistake and the flavor has gone. Warm the pot first. Always boil fresh water (soft water is best) and infuse the tea for three to five minutes, perhaps longer in hard-water areas, stirring the pot occasionally. Use one rounded teaspoonful of tea for each cup required. You will find that a six-minute infusion is required if tea is to be drunk with milk because the casein in the milk reacts with the Tannin.

Tea should be served in a quiet room away from the phones and screens. I have never been able to get hold of a professional Master of ceremonies, such as a Geisha, but one can take this role in turns. The Master of Ceremonies works very like a Chairman. Nobody is allowed to dominate the conversation, or to get overly technical. The ceremony ends in fifteen minutes. Any mention of post-it notes, pigs or chickens is banned.

The subject of Biscuits is contentious. I have even heard tell of chocolate biscuits being served, but I think that the line must be drawn here. If biscuits are served, they should be plain, so as not to detract from the delicate flavor of the tea. Dunking is anathema.

A final word about Milk and Sugar: Milk is allowable, so long as the tea is prepared specially for the addition of milk. Sugar ruins anything it is added to, and destroys the taste of tea. The Health Stasi who interfere with our natural god-given wholesome human right to the occasional Sumatran Cigar would expend their beastly energies to far greater good by pursuing the disgusting habit of adding sugar to tea.

Ever since I was initiated to the idea of Tea Ceremony in development teams, I have introduced it many times with great success. Unlike Agile Scrums, the practice leads to peace, harmony and a clear head. I once encountered some resistance when introducing the tea ceremony to a development team of rough Essex people near Southend. They called the glorious Formosa Oolong that I bought for them ‘Poofy Tea’, a name that somehow stuck. They took a long time to come to terms with the idea that Dunking was an unnatural vice, and that sugar was a vile drug. They knuckled down eventually, became converts, and ended up enthusiastically trying all sorts of way-out teas. One day, I shall tell the story of the tranquilizing effects of Elderflower Tea, Hop Tea and Apricot tea in the workplace.

‘Technical Interviews’ have got to stop. They are a disgrace to the IT profession.  Two MVPs who I asked the question ‘Have you ever passed a technical interview’ have admitted ‘Never’.  I’d like more successful developers to confess their inability to remember much more than their name under the pressure of a technical interview.  The most extreme geeks all have brains that blue-screen with a temporary aphasia under  stress.

I have a new proposal to make. Instead of employing developers after asking them a series of trivia based from trawling obscure facts in MSDN, you should see how good they are at Table Tennis, Table footie, or guitar. I might include pool/Billiards too. 

I intend to justify this apparently ludicrous assertion

There are many theories of what makes a good developer. In the 1960s, when the shortage of people with IT skills first became apparent, people were selected on their mathematical skills. This proved to be disastrous, and IT departments soon filled with strange geeky folk devoid of social skills, or any understanding of real business applications. This puzzled the recruiters who consulted the psychologists. The Psychologists pondered over this and, in the fashion of the time, came up with a set of problem-solving tests based on Hans Eysenck’s intelligence tests.  In Britain, these seemed so obviously appropriate that they even appeared on adverts ‘If you can solve this puzzle in five minutes, call xxxxx’.  Subsequent exercises in validation showed that they were no more successful than chance in successfully predicting a good IT programmer. In fact, it just told you that the person was good at puzzles; it also suggested that they didn’t get out enough in the evenings. The psychologists then took the more sensible approach of testing real successful IT programmers, and seeing what their skill-set consisted of. It turned out that good programmers were very articulate.  Otherwise, they had no obvious dominant skill in common.

Selecting programmers who were good at language skills just didn’t look right. It had no ‘Face Validation’, and it didn’t impress the brash new profession of ‘HR’. They wanted tests like they had at school. Where there is a demand, there are always people prepared to supply it, and soon a lucrative market in Technical tests developed.  The validation of any psychometric test of ability is a highly technical subject which I won’t bore you with.  Please just remember that, because these many tests of technical competence have never been scientifically validated, they are no more effective in selecting the good candidates than testing to see if the applicant can sing ‘Somewhere over the rainbow’ in a high voice.  The classic Microsoft interview questions, such as ‘Why are manhole covers round?’ shouldn’t be used until you can prove that successful programmers believe (wrongly, it turns out) that it is to stop the covers dropping into the hole, more frequently than do the duffers.

Besides fluency with spoken language, there is another essential component, a personality trait that is necessary for a good developer. This is a cussed stubbornness that won’t let go of a problem until he or she has solved it.  It is that will to go through pain, boredom, hunger, and lack of sleep in pursuit of doing something that is almost impossible…. Such as playing guitar properly, solving advanced physics and mathematical problems, playing badminton or table Tennis well. 

The best programmers I’ve ever met are astonishingly alike in this respect. If they can’t get something in their lives to work as well as they want, it turns into a man-machine struggle of epic proportions. If I give someone a programming puzzle to solve in an interview, the good programmers don’t necessarily know the answer; the good programmers refuse to finish the interview until they’ve got the answer right. It suddenly rears up in their minds as being even more important than the interview. The whole objective of getting a job is temporarily put to one side in pursuit of a solution.

The same personality, if she, or he, finds himself unable to play table-tennis properly, or play ‘tiptoe through the tulips’ on the ukulele, or beat the regulars at Pool, will bloody practice until she, or he, does or renders himself or herself incapacitated in the attempt.

If you think that this is an absurd theory, you will be surprised to hear that the standard American test of mathematics, which is prefaced by a rather long-winded form for name, address etc. , has an almost perfect correlation between the Mathematics score and the ability to fill in the preliminary form accurately. If the applicant has the mental stamina and obstinacy to apply to fill in the preliminary form you can be certain that he or she will be good at Maths.  That same cussedness turns out a good IT programmer, or a good table-tennis player, or any skill that required dogged determination.

So, if I ever have to interview you for a technical development job, have no fear of being taxed with knowledge of obscure parameters to DBCC functions you would never dream of using, or obscure behavior of Transaction rollback in linked servers; No, beyond establishing a sound ability to understand questions and solve general programming problems, I shall be there to challenge you to a game of table football, croquet,  pool,  or any other skill  that can only be achieved by bone-headed  stubbornness and practice beyond the patience of an ordinary mortal.

Should you insult posters on newsgroups, forums or online discussions?  This may be a strange question to ask, and the answer is generally "no". It is a bad idea, even though your target is usually too far away to exact retribution:  Occasionally, however, the urge to insult someone who posts on a forum is irresistible.

Most people on forums are remarkably patient with their fellow posters. This may, at least in part, be because they realize that no-one is immune from the occasional embarrassing gaffe. Many forum posts are written hurriedly.  Those of us who do a lot of posting tend to do so in a few stolen moments. As I write this, I’m finishing off a quick lunch (banana), and sipping coffee. There are a stack of things I should be doing. This haste can lead to unpolished text and phrases conjured up on the spur of the moment.  We make mistakes. We don’t finesse our responses. And this in turn can lead to incredulity and confusion in our fellow posters.

As a result, most posters refrain from directing scorn or ridicule at other forum members, or at least have very long fuses. There will come a time however when one feels provoked beyond endurance and the desire to let a person know what you really think is irresistible.

What should one do in these circumstances?

The Problems

If I was going there, I wouldn’t start from here

The first problem with insulting someone in a forum is that it could be you who has misunderstood. A common mistake is when someone asks how to do something that looks completely idiotic. The first instinct is to assume that they obviously haven’t thought out the algorithm or business process, and to sweep the question aside with a contemptuous ‘tell me what you are really trying to achieve’, or the like. Usually you are right, but occasionally you will find that they have been told to do it that way by the pointy-headed boss who pays their salary.  Alternatively, they will be engaged in the miserable and unrewarding task of having to maintain a ‘Mad’ database system that has somehow got into production. Once in a while, they may actually have a good idea that you are too busy to appreciate.

Moral: Always give a possible direct solution to their problem before tactfully pointing out that there may be a better alternative. Nothing is achieved by implying that they are a lower form of life.

Language Imperialism

The SQL Community is very international.  It is forced to speak English as the language of Technology, just as Latin was the language of Academia until three hundred years ago. It isn’t easy for most of us. If the English is clearly the second language of the forum poster, and you use slang or complex metaphor in a comment, then these are easily misinterpreted.  Many a phrase, used in a lighthearted way, can be horribly insulting or humiliating when seen from the viewpoint of a different culture, especially to a Scotsman.

Moral: Any mocking of the English language of a poster in a forum is completely off-limits.  If ever you feel inclined to do this, and you are an English speaker, then try learning Ancient Greek just to put yourself in their shoes. It isn’t easy.

The Art of Vituperation

The third problem with insulting people is that vituperation is an art, like ballet. And, like ballet, if you attempt to do it without great expertise you merely look ridiculous.

Moral: Mark Twain, Dorothy Parker or Auberon Waugh could do vituperation to perfection. I doubt if you can, so avoid it.

Mocking Beginners

The habit of mocking beginners, deriding them as ‘Newbies’ or jeering at them because they don’t appreciate the etiquette of the forum,  usually makes the mocker seem ridiculous and, much more importantly, can put people off using the forum.

It is possible that a potentially talented author, submitting a first tentative articles or querulous forum posting, can get crushed by an unconsidered comment. Consider also that the beginner you mock and humiliate on the forum today may one day, and sooner than you think, become an expert and opinion leader.  It is never a good idea that such people are left smarting from one of your clumsy rebukes

Moral: In the history of warfare, certain weapons have killed more of the people who pulled the triggers than their intended targets. Think carefully before taking aim.

A suggestion

Am I suggesting that we should all be on our best behavior, at all times, in forums or Newsgroups?  No! Forums are fun to read, and participate in, when you can detect that the entries are written by real humans with diverse moods and emotions. If you take out all the emotion, then forums lose their fizz. All I’m saying is that, if you are going to show anger, impatience, or contempt, in your forum post, then it has to be done properly, at the right time, or not at all.

The answer, I think, was given to me a long time ago when I worked for an eminent consultant pediatrician in a hospital.  He had the delicate task of writing letters to doctors who had referred patients to him. Often he had to give them the news that they had misdiagnosed the patient, wasted a lot of time, caused suffering unnecessarily, or even hastened the patient’s demise.  In private, behind closed doors, he would wax vitriolic about the dangerous incompetence of the doctor concerned. The letters, however, would be effusive with compliments; any criticism was hedged about with lashings of thickly-spread flattery.

I was a young hothead, and I eventually asked him why his letters were so mealy mouthed. I didn’t get it.

"Nobody is immune from politeness and flattery", he told me. "In fact, there seems to be no upper-limit to the amount of flattery that a person can absorb. If you can compliment and encourage the person that you must instruct, then any reproach is accepted more readily. There are ways of phrasing a painful truth about a person’s skills or conduct that will deflect hurt feelings, and therefore be accepted more readily. All you get by haranguing people for their foolishness is resentful resistance."

I highly recommended application of this technique in forum posting. When the urge to flame somebody strikes,  rephrase your thoughts in such a way that the person is impelled into doing the right thing, but does not feel insulted. A nice fringe benefit to this process is that it provides a wonderful way of managing one’s anger and frustration.

Here are a few examples of this technique in action, to give you the idea:

What You Say	What You Mean
Your excellent DDL script which accompanied this question has somehow become detached.  This has meant that we are struggling to understand the problem.	How the hell can we work out what you mean if you haven’t even sufficient blood-sugar to supply the code?
It is kind of you to let us see a sample of the kind of questions posed by teachers, but I suspect that they are designed to work best if undertaken by the student and not appropriate here.	I’ll roast in hell before helping you with your IT School homework-unless I get your diploma, of course.
I suspect that you are too busy to have had any opportunity to read any previous forum entries on this subject.	This same question has been answered several times today already. Your brain is in write-only mode.
I suspect that there is a subtlety to this problem that is not immediately apparent.	Do they have databases on your planet?
I apologize for not being able to explain the solution to your  problem sufficiently clearly	The only solution is for you to do something else for a few thousand years so as to give evolution a chance.
It is fascinating to be reminded of this sort of SQL problem. It does not often come up.	Last time I saw this was when John asked Janet this in ‘Janet and John's ABC Guide to SQL'
I have got a curious sense of 'Deja-vue' in reading this excellent posting	You've made me a cross poster because you are a cross-poster.

 

Having mastered this subtle art, you will find life on the forum far less stressful, and more rewarding, and those "in the know" will understand that you are writing is not necessarily the same as what you are thinking.

”Ere mate,” came the voice from behind me, “you’re sitting in my chair. I want it back.” He looked at me, red in the face and indignant.  He didn’t actually say it, but the look he was giving me spoke volumes. You are pissing on my lamppost.

I looked around. Within a few feet, there were a group of identical office chairs, all empty, congregated in a little group.

I was visiting a client’s office and talking to one of their database people about a problem. It was a complex explanation, and I’d given my slightly arthritic knee a slight rest by sitting down on the nearest empty chair to hand. The owner had returned, and started a reenactment of Goldilocks and the Three Bears. 'Who'se that sitting in MY Chair?'. I had inadvertently invaded his personal space.

I looked up at the protesting office worker.  It is a worrying sign when the disease of institutionalisation has progressed to the point where the sufferer must have his own chair.

I should explain that, if you spend too much time in any one workplace or any communal space, particularly if your life is unstimulating, you are in danger of institutionalization. Amongst other symptoms, the chair you sit on becomes increasingly psychologically important. The great poet and author Brian O'Nolan, writing under the pseudonym Flann O'Brien, in his book 'The Third Policeman', invented the fantastic allegory that policemen who rode their bicycles so much over rough roads that  part of their soul entered the bicycle, and some of the spirit of the bicycle entered their soul. In the same way, the red-faced office worker felt subconsciously that I was sitting on part of him. The other part of him that was not now office-chair, resented the fact. Similarly, it was once said of a politician 'he spent so long sitting on the fence that the iron entered his soul'.

Mankind was designed to roam the shorelines of the world in small family groups, gathering fish, nuts and herbs.  Office-life is a strange, alien environment that slowly erodes that wild creative independent streak. Like the long term inmates of a psychiatric ward or prisons, the ‘trusties’ in an office settle down over the years and become passive, submissive, less trouble, but at what cost?

I remember vividly the leaving parties for the old chaps who were retiring from the vast international company where I once worked, after a lifetime’s service. White haired, but hale and hearty, they would leave their old familiar workplace, speaking bravely of putting their feet up, doing a bit of gardening, popping down the pub every lunchtime.  For us that shook their hands, and wished them happiness, it was a poignant moment. Almost invariably, we’d be attending their funeral within months. Sudden freedom from a lifetime’s incarceration in a stultifying and all-providing workplace can be highly stressful.  Cold Turkey from institutionalisation is a mistaken kindness. Anyone who has been imprisoned will describe the long hard road to rehabilitation after release. We should be wandering along the shore, gathering shellfish, not festering inside concrete walls, staring at computer screens.The damage to our free-will is subtle but longstanding.

I looked up at the ‘owner’ of the chair. Should I explain to him the danger to his psyche?  Should I pull him back from the brink by refusing his request? No, I took the coward’s way out and gave him back the chair, and hobbled over to get myself another one. I felt slightly gutless at not having done the decent thing by staying put on 'his' chair.

I resumed my conversation with the DBA about indexing strategies and so on, but occasionally glanced over at  The Chair Man, who had subsided into surly obeisance of his  keyboard and  screen, like a  priest at an icon, fumbling prayer-beads.  I gradually wondered if I should try what I call the Factor Test. This is a test which any of you can try, which gives a measure of the degree of institutionalisation of the office worker.  You ask if you can borrow one of his office pens. (Of course, you must ensure that they really belong to the company, not a personal possession.)

Sure, Is one enough?	(Scores 0. unharmed)
Be my guest, mate!	(Scores 1, healthy)
Well OK, but there are plenty in the stationary cupboard	Scores 2, concerning)
Just this once, but why not get your own…	(Scores 3 very worrying)
No	(Scores 4: Beyond rescue)

Together with other significant tests, one can soon single out the people in danger of slipping into a distorted reality.

The Chair Man had worrying symptoms. Pens were festooned in neat groups around his  desk. I decided to try out the Factor Test. I wanted to draw a diagram of the way that clustered indexes work  so I got my notebook out, and pretended to fumble around my pockets for my pen. I turned around to the Chair Man. ‘Excuse me, may I borrow your pen?’
‘Sorry, I haven’t got a spare one’

Oh dear, that scores four.  There is an emergency procedure for acute sufferers of institutionalization, equivalent to the The Heimlich manoeuvre, which  is used for the removal of airways obstruction in a choking patient. Unlike the Heimlich manoeuvre, the sufferer is generally ungrateful, through being unaware that their soul has been rescued from the grim embrace of institutionalisation. I once did it to a senior executive at Rank Xerox.  You sit in their chair, and grab at all their company pens and pencils, stuffing them into your pockets,  whilst singing loudly ‘Pop goes the Weasel’. Then you rush off, laughing. Surprisingly, it gave me an almost demi-god status amongst the other senior executives when they got to hear about it. I never had to my my own drinks in the pub after work ever again.

Should I administer this procedure? Call me a wimp if you like, but at a time when I could have saved the chap from his slide into half-life, I did not proceed, but carried on with the session with the Database Administrator. I felt slightly bad about it, so I did second-best. When I got up at the end of my chat, I noticed with a surge of delight that my chair was one of those absurd plastic constructions with castors that you can push around like a  Bath Chair. A quick flick with my leg and the chair flew back and crashed against the desk next to Chair Man. His life had had a sudden, apparently disagreeable, shock. It had, however, administered a theraputic change into the quiet complacent unchanging tranquility of his existence. For a moment I thought he might try to hit me, but he thought better of it.

I was pleased. I bade them farewell with the contentment that comes from having brought back a flicker of humanity into an institutionalized life. Perhaps, one day, he will realise the act of kindness and thank me.

The Devils Manual for IT Managers

Part 5: Looking Busy

This is the fifth in my series of hints for aspiring IT managers. Here, we tell you how to look busy and efficient,

Note the previous four blogs in the series

1. Part 1: How to prevent Initiatives
2. Part 2: Irregular verbs for IT managers
3. Part 3: Phrases with which to discourage ideas.
4. Part 4: Writing a 'one-pager' strategy document.

The most important thing for an IT manager is to look busy. In fact, it is a technique that dominates the management of the public sector, where whole office blocks are filled with people earnestly engaged  in nothing more than sending emails to each other full of positioning papers, strategy documents, directives and plans. Looking busy is one of the primary skills that is required in a manager, and one looks in vain for sage advice on this in the manuals on management that are sold in airports. to fill a crying need, I offer the following tips.

• Be creative in stagggering your hours: I once knew a manager who arrived early at the office and always was the last to leave. It impressed everyone, and nobody seemed to realise that he, legitimately, took four hours off in the middle of the day.
• Spend your time at a PC. The PC is a wonderful invention because it is almost impossible to detect whether the user is doing productive work or not. An entire office can be seen bent over terminals engaged in work of mysterious complexity, when the are, in fact, doing nothing more than updating their facebook profile or organising their social life.
• Project-management software is essential. This is because just a small amount of data will produce reams of print-outs with esoteric graphs, calculations and reports. When ever anybody queries the status of one of your projects, just hand them the folder with all the printouts. The more data you put into project-management software, the more wildly impressive it looks.
• Attend lots of meetings. It is important to note that if you call lots of meetings with other people in your own company, they eventually get bored and don't turn up. Suppliers, and potential suppliers, are different: they always turn up, especially if you are buying from them. Even if you don't, you can string them along for a long while, and then you can just choose a different set.
• Engage in 'crisis management', pursue just the most visible' parts of the job. It always helps to drop into conversation a mention of the feats of management you regularly accomplish
• Make sure you get lots of SMS, phone and mobile calls (you will achieve this by putting ads in the local papers).
• Make lots of visits to other offices within your organisation. There's no need to do anything when you're there, but it looks good, and is useful for dropping in the conversation subsequently, thereby paying a double dividend. Once everyone is aware of your peripatetic habits, nobody will even realise when occasional visits are to the golf course.
• Keep a box full of files which you strew all over your desk in neat piles when you get in. Before you go, just stack them away again, thereby getting a reputation for efficiency as well. A successful modification of this technique is to dump the files into your in-tray, thereby impressing all with your workload as well.
• Revise all the documents that your subordinates submit to you for approval. You will enjoy this too, since there is no passion like the passion to revise someone else's document.
• Spend lots of time organizing your time. That way, you look busy and efficient, even though you will not have the time left to do the things you have organized yourself to do.
• When challenged as to why you have not done something you chuckle confidently, say 'that would have been too simple, what we are doing is studying the underlying processes, and understanding the fundamental requirements of the users', and lean back in your chair with a smug smile.
• Never miss a chance to (loudly) complain how many mail items arrive whilst you are away from your desk (this is a major indicator of your importance) . It pays to turn the sound up on your PC so others can hear the emails arrive.
• Engage in a vigorous Email correspondence with a large number of other managers, making sure you rush round telling everybody about the huge number of unread Emails in your mailbox. Achieve this by putting a question at the end of every email you send out.
• In meetings, be prepared with a number of Powerpoint presentations. The quality is immaterial as these are devised to reduce your audience to a state of induced catatonia. Always aim to say as much as possible. if there is a white board, be sure to get control of the felt-tips.