jump to navigation

Friday Philosophy – The Secret to Being a Good IT Manager June 3, 2011

Posted by mwidlake in Friday Philosophy, humour, Management.
Tags: , ,
10 comments

If you go into a book shop there will probably be a section on business and, if there is, there will almost certainly be a load of books on how to be a manager. Shelves and shelves of them. There is also a large and vibrant market in selling courses on management and aspects of management. I’ve been on a couple of such course and, if you can manage to be open minded whilst keeping a cynical edge, I think they can be useful.

However, I think I most of them are missing the key points and that if you can but hold on to the following extensive list of guiding principles you will be a good IT manager. Maybe even an excellent one :-):

  1. Your top priority, at all times, is to see to the best interests of your people.
  2. Whatever you develop, be it code, databases, network, a team of support staff – User Acceptance is paramount.
  3. You must find ways to deal with other teams and your own management hierarchy in such a way as to be allowed to do (1) and (2).
  4. That’s it.
  5. OK, if pushed, I’d say Never Lie. Maybe that’s just personal though, it’s because I don’t have the memory, audacity or swiftness of mind to pull it off. By not lying I don’t have to try and construct what I said to who and why.

I’m sure people could cite some other hard rules like “you must be within budget” or “you need to get buy-in to your vision” but I don’t agree. Budgets can be negotiated and the difference between those deemed visionaries and those deemed fantasists seems to be to me down to success and luck. Luck is luck and for success I refer you to points 1 through 5.

OK, maybe a final rule is:

  • Never ask for or aim for something that is not realistic.

So, I am now able to develop my team and my application and not expect to be able to spend half the company profit on the fastest box out there, as it is not realistic.

There are a shed load of other things that I think are important to helping you be a good manager, you know, techniques and methods for improving things, but nothing else that is key.

And it’s such a simple, small list even I can aim for it.

The shame of it is that I don’t think it’s enough to be developed into a book or a course so I can’t sell the idea. That and I’ve gone and given it away in this blog. Also, though I feel I can give points 1,2 and 5 a good shot, point 3 is way beyond me…possibly because of point 5… So I am not a great manager.

I’m going to hide behind this stout wall now, with my hard hat on, and wait to be told how naive I am…

Update – A couple of weeks later, Kellyn on her DBA Kevlar blog put similar sentiments to looking after your guys, more from the employee’s perspective and far better covered

Why given so many of us feel this way and want things to be this way…are they not?

Telling the Truth in IT March 17, 2011

Posted by mwidlake in Meeting notes.
Tags: , ,
8 comments

I’ve been doing presentations for many years, mostly on Oracle Technology, occasionally on management topics. However, my favorite presentation to give is one about when things go wrong.

The title is usually something like “Surviving Survivable Disasters” or “5 ways to Seriously Screw up a Project” and, though the specific examples and flow may vary, the general content is the same. I talk about IT situations that have gone wrong or things that strike me as daft/silly/mindless in IT. My aim is to be entertaining and have a laugh at the situations but I also want to explore what causes disasters and how we might go about avoiding at least some of them.

When doing the presentation I have a couple of ground rules:

  • I must have witnessed the situation myself or know personally, and trust, the individual who is my source.
  • I do not name organisations or individuals unless I am specifically given permission {by individuals that is, organisations never get named. Except one}.
  • I try to resist the temptation to embellish. It’s not hard to resists, a good disaster usually stands on it’s own merits.

It’s a great talk for introducing some light relief into a series of very technical presentations or for opening up a day of talks, to get people relaxed. It’s also the only talk I get seriously nervous about doing – if you are aiming to be entertaining and you miss, you stand to die on stage. The first time I did the talk I was physically sweating. However, it went down a storm. I did it 4 or 5 more times over as many years and it always went down well.

However, about 4 years ago I did the presentation just as I was about to go back to being self employed. After the talk a very good friend came over and said something like “Really entertaining talk but…maybe you should tone it down? A lot. Potential employers are going to take a dim view of you doing this, they will worry they will appear in the next talk”. I protested that I never mention companies or people and, surely, all organisations are able to admit that things go wrong and it is to everyone’s benefit if we all learn from them? My friend was adamant that though companies want to benefit from other disasters, they never, ever want to in any way be the source of that benefit. He was sure it would be very damaging to my potential career. Hmmmm…. I could see his point.

I was already scheduled to do the talk again in a couple of months and I took heed of his advice for it. I toned down the material, I removed some of the best stories and I added several disclaimers. I also died on stage. It went from an amusing 45 minutes to a preachy and stodgy affair.

I have not done it since.

The question is, should I have pulled back from doing that talk? Is it really going to harm my potential employability? (After all, no work has ever come my way from presenting). Why can’t we be honest that issues occur and that learning from them is far more valuable than covering them up? After all, do we believe a person who claims never to have made mistakes?

What prompted this thread is that I have been asked to do the talk again – and I have agreed to do so. I’ll be doing it next week, with the title “5 ways to advance your career through IT Disasters” for the UK Oracle user group Back to Basics event. This is a day of introductory talks for people who are fairly new to Oracle, the brain-child of Lisa Dobson. Lisa realised a few years ago that there were not enough intro-type presentations, most technical talks are by experts for fellow experts {or, at least, people wanting to become experts}.

I’m very happy to support helping those who are new to Oracle and I think it is important that people who are new to IT are exposed to what can go wrong – and any advice that might help them avoid it. After all, it’s better they learn from our mistakes than just repeat them again. OK, they’ll just repeat them again anyway, but they might spot that they are doing so just in time :-)

Is this a good idea? What the hell, I want more free time to do things like this blog – and get on top of the garden.

You can explain an invalid SQL statement November 27, 2010

Posted by mwidlake in internals.
Tags: , ,
6 comments

I’m in “nightmare weekend before presenting” mode. I’m up to my eyes at work (and have been for ages, thus the quiet blog) and my recent weekends have been full of normal {and abnormal} life.

As is the way, when up against it and putting together my proofs for wild claims, everything breaks subtly and makes my wild claims look a little, well, wild – even though they are real issues I’ve seen, worked through and fixed in the day job. *sigh*. It does not help when you come across little oddities you have never seen before and end up spending valuable time looking into them.

So here is one. I’m just putting together a very, very simple demo of how the number of rows the CBO expects to see drops off as you move outside the known range. In the below you can see the statement I am using (I keep passing in different days of the month and watching the expected number of rows drop until I hit 1 expected row), but look at how it progress to the last entry…

mdw11> select count(*) from date_test_flat where date_1=to_date('&day-02-2011','DD-MM-YYYY')
  2  /
Enter value for day: 01

Execution Plan
----------------------------------------------------------
Plan hash value: 247163334

-------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |     1 |     8 |   215   (0)| 00:00:04 |
|   1 |  SORT AGGREGATE    |                |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| DATE_TEST_FLAT |    16 |   128 |   215   (0)| 00:00:04 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("DATE_1"=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss'))

mdw11> /
Enter value for day: 15

Execution Plan
----------------------------------------------------------
Plan hash value: 247163334

-------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |     1 |     8 |   215   (0)| 00:00:04 |
|   1 |  SORT AGGREGATE    |                |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| DATE_TEST_FLAT |     2 |    16 |   215   (0)| 00:00:04 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("DATE_1"=TO_DATE(' 2011-02-15 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss'))

mdw11> /
Enter value for day: 21

Execution Plan
----------------------------------------------------------
Plan hash value: 247163334

-------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |     1 |     8 |   215   (0)| 00:00:04 |
|   1 |  SORT AGGREGATE    |                |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| DATE_TEST_FLAT |     1 |     8 |   215   (0)| 00:00:04 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("DATE_1"=TO_DATE(' 2011-02-21 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss'))

mdw11> /
Enter value for day: 30

Execution Plan
----------------------------------------------------------
Plan hash value: 247163334

-------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |     1 |     8 |   215   (0)| 00:00:04 |
|   1 |  SORT AGGREGATE    |                |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| DATE_TEST_FLAT |    99 |   792 |   215   (0)| 00:00:04 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("DATE_1"=TO_DATE('30-02-2011','DD-MM-YYYY'))

mdw11>

The expected number of rows drops, becomes and – and has shot up to 99 again (which is the expected number in the known range, as I have 10,000 rows spread over 100 days). My immediate thought is “Wow! Maybe Oracle have put some odd fix in where when you go well out of range it reverts to expecting an average number of rows”. Nope. It is because I asked for the data for 30th February. And I did not get an error.

I think it is because I have set autotrace traceonly explain. This causes the SQL statement not to be executed {if it is just a select, not an insert, update or delete}. It seems the costing section of the CBO is not so good at spotting duff dates, but it then gets the costing wrong.

I’ve spotted that the format of the filter also changes when the date is invalid, I really want to check that out – but I better continue failing to write the presentation!

I know, pretty pointless knowing this but it just amused me. Below is just a quick continuation to show that if the statment is to be executed you get an error and no plan and that utterly duff dates can be passed in.

mdw11> /
Enter value for day: 28

Execution Plan
----------------------------------------------------------
Plan hash value: 247163334

-------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |     1 |     8 |   215   (0)| 00:00:04 |
|   1 |  SORT AGGREGATE    |                |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| DATE_TEST_FLAT |     1 |     8 |   215   (0)| 00:00:04 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("DATE_1"=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss'))

mdw11> SET AUTOTRACE ON
mdw11> /
Enter value for day: 20
any key>

  COUNT(*)
----------
         0

1 row selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 247163334

-------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |     1 |     8 |   215   (0)| 00:00:04 |
|   1 |  SORT AGGREGATE    |                |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| DATE_TEST_FLAT |     1 |     8 |   215   (0)| 00:00:04 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("DATE_1"=TO_DATE(' 2011-02-20 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss'))


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        821  consistent gets
          0  physical reads
          0  redo size
        421  bytes sent via SQL*Net to client
        415  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

mdw11> /
Enter value for day: 30
select count(*) from date_test_flat where date_1=to_date('30-02-2011','DD-MM-YYYY')
                                                         *
ERROR at line 1:
ORA-01839: date not valid for month specified


mdw11> set autotrace traceonly explain
mdw11> /
Enter value for day: 30

Execution Plan
----------------------------------------------------------
Plan hash value: 247163334

-------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |     1 |     8 |   215   (0)| 00:00:04 |
|   1 |  SORT AGGREGATE    |                |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| DATE_TEST_FLAT |    99 |   792 |   215   (0)| 00:00:04 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("DATE_1"=TO_DATE('30-02-2011','DD-MM-YYYY'))

mdw11> /
Enter value for day: 45

Execution Plan
----------------------------------------------------------
Plan hash value: 247163334

-------------------------------------------------------------------------------------
| Id  | Operation          | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                |     1 |     8 |   215   (0)| 00:00:04 |
|   1 |  SORT AGGREGATE    |                |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| DATE_TEST_FLAT |    99 |   792 |   215   (0)| 00:00:04 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("DATE_1"=TO_DATE('45-02-2011','DD-MM-YYYY'))

Friday Philosophy – The Worst IT Person I Have Met October 15, 2010

Posted by mwidlake in Friday Philosophy.
Tags: , , ,
9 comments

A couple of weeks ago I extolled the virtues of someone I felt was a great person to work with. This week I’m going to do the opposite (and it will be interesting to see which posting gets more hits).

The worst person I have worked with in IT is Mick. I’ve only known a couple of Micks {and if you are one of them, but you don’t know Barry, you are not the Mick}. In an ironic twist of fate I met Mick at the same time I met the best person I have worked with, Barry. We were all in the same team you see, a UNIX sys admin team I got parachuted into. Maybe the vast difference between the two help make them so distinct in my mind.

Mick was very knowledgable and technically very capable. No, that is not fair, he was extremely good. He actually knew all this system admin stuff and several variations of shell programming, perl, C and a few other two-steps-from-assembler type languages. And he was an absolute and utter pain in the behind.

Barry and I did not know much (or in some cases, any) of this sys admin stuff. If we needed to do something and did not know how, Mick was supposed to show us. It worked something like this:

“Mick, I need to copy all the files that were changed last week from this directory on box X to box Y, keeping the directory structure – Can you help?”. Mick would not hear. He suffered from “intermittent deafness” – though he never missed any announcements about free food. You had to go and stand by Mick and wait for him to deem to notice you. If you actually interrupted him he would swear at you and utterly refuse to help, you had to wait quietly. If it was a good day he would deem this acceptable after a minute or two, but he would do his utmost to convey the impression he despised your lack of knowledge and your concerns were beneath his talents… but he would stoop to help.

You would repeat the task you were trying to do and, pausing only briefly to pour scorn on such a trivial thing, he would turn his back and start typing. He’d write a script to do it. “no, no, don’t write it, just tell me the basic commands and I’ll work it out!” No, he insisted on writing the script.

The script would be a thing to behold. Mick would write it in as few lines as possible and the least number of letters. For ages. Oh, he would have a working version in about the time it took Barry or I to explain the task, but he would not give you that version, oh no. He would ignore you until he had made all variables 1 character, took out all whitespace, replaced anything obvious with something obtuse, replaced a small chain of simple commands with one or two arcane commands. Every script was an attempt to win an “obfuscated code” competition. If we waited for the end result, it was impossible for Barry or I to decipher. The only benefit to the process was you would see the commands he was using and you could wander off and start with the unix Manuals yourself and get the job done.

He had other methods with which to demonstrate his greater worth.
Mick would agree to help (under duress of the boss telling him to do so) with an urgent task, but keep asking you to wait all day – then go home without doing his bit.
He seemed to love to intercept anyone coming to you for help, tell them he would sort out the problem for them – only to not. And then tell the user the next day that it was Barry or My problem to sort out. Correct, Mick would not have mentioned this to us.

Mick was fair though, he would treat everyone the same. With scorn. Any expertise in a field he did not know was unimportant and anyone with skills in his field was just competition to be shown who was best. Sadly, he usually was best, if best means biggest smartass.

Over time, as Barry and I learnt stuff (almost never from him), Mick became redundant. Not because we caught him up, not by a long way, but because no one else in the department would ask him anything. They would come to Barry and I. We might be slow and we sometimes screwed it up but we did not sneer and we fixed the problem in a way they could understand.

The reason Mick is the worst person I ever worked with is, unlike people who simply break stuff or lie about their skills or are stupid, he was actually very talented and capable – and yet took a perverse pleasure in not doing so. Mick would put effort into the art of maximizing his unhelpfulness. It was the difference between his potential to help and his drive to not do so that made it so hard for me to deal with him. I’d rather work with a talentless, idiot liar because at least you don’t need or expect much from them.

*sigh*

Team Work & The Science of Slacking July 23, 2010

Posted by mwidlake in Friday Philosophy, Management, Perceptions.
Tags: , , ,
add a comment

We all know that working in a team is more efficient than working on your own (and I did say a week or two back how I was enjoying the rare privilege of working in a team of performance guys). Many of us also know about team dynamics and creating a balanced team of ideas people, completer-finishers, implementers, strategists and so forth. Those of use who have been exposed to training courses or books on team management know all these good things about teams and how we are supposed to get the most out of them.

How many of us, though, have been introduced to the work of the French Agronomist Max Ringelmann and the aspect of teams named after him, the Ringelmann Effect? In summary the Ringelmann Effect proposses that people in teams try less hard than they do when working alone. Especially if they think no one is watching them.

Back at the start of the 20th century Ringelmann tested out his ideas using a tug-of-war experiment. He would get people to pull on a rope as hard as they could and record their efforts using a strain gauge. Then he would get them to pull on the rope as part of a team, from 2 to 8 people. As soon as people were part of a team, they pulled less hard. With two people in the team, each pulled 93% as hard as on their own, with three people this dropped down to 85% and with 4 it was just 77%. By the time there were 8 people in the team, effort was down to 50%.

This idea of shirking work more and more as the team increased in size became established in modern psychology and was given Mr Ringelmann’s name. Psychologists explain that when someone is part of a group effort then the outcome is not solely down to the individual and, as such, is not totally in their control. This acts as a demotivating factor and the person tries that little bit less hard. The larger the team, the greater the demotivation and the more significant the drop in effort. Ringelmann found that effort was down to 50% in a team of 8 so how bad can the impact of the team be? I think most of us have at least witnessed, and quite possibly been in, the position of feeling like just a cog in a massive corporate team machine. Thoroughly demotivating (though, of course, we all of us still tried as hard as we could, didn’t we?).

The effect is also know under the far more entertaining title of Social Loafing.

Monsieur Ringelmann was far kinder at the time and pointed out that these chaps pulling on the rope could well have been suffering from a lack of synergy. They had not been trained together to pull as a team so that could account for the drop in effort, they were not synchronising their effort.

However, in the 1970’s Alan Ingham in Washington University revisited Ringelmanns work and he was far sneekier. Sorry, he was a more rigorous scientist. He used stooges in his team of rope-pullers, blindfolds and putting the one poor person pulling for real at the front of the team pulling the rope. Thus he could record the effort of the individual. Ingham found that there was indeed a drop in efficiency due to the team not pulling as one. But sadly, this was not the main factor. It remained that the drop in effort was mostly down to the perceived size of the rest of the team. The bottom line was proven to be the human capacity to try less hard when part of a team and that the drop in effort was directly proportional to the size of the team.

We are of course not immune to this effect in the IT world and someone has even gone to the effort of checking that out, James Suleiman and Richard T Watson.

It seems the ways to reduce this problem are:-

  • Don’t give people boring jobs.
  • Don’t give the same job to several people and let them know they all have the same job.
  • Ask people how they are getting on and give them mini-goals along the way.
  • Atually reward them for success. Like saying “thank you” and NOT giving them yet another boring, hard job to do as they did the last one so well.

I think it is also a good argument for keeping teams small {I personally think 5 or 6 people is ideal} and split up large projects such that a single team can cope. Then give tasks to individuals or pairs of people.

If you like this sort of thing you might want to check out one of my first blog post (though it is more an angry rant than a true discussion ofthe topic) which was on the Dunning-Kruger effect, where some people are unaware of their own limitations – though I did not know it was called the Dunning-Kruger effect until others told me, which only goes to show that maybe I am not aware of my own limits… Read the comments or click through to the links from there to get a better description of some people’s inability to guage their own inabilities.

My laptop has a Bug July 20, 2010

Posted by mwidlake in biology.
Tags: ,
add a comment

My laptop is suffering from bugs, and I’m not talking software.

It is warm and sunny here in the Southeast of England, which is not always the case during the British Summer, and I am suffering an invasion of little insects. Specifically Thrips or Thunderbugs. They are called Thunderbugs as they are supposed to appear in numbers when a thunderstorm is brewing. Like most Old Wives Tales it is utter rubbish. But kind of true too…

If you do not know, a thrip is usually a small insect about 0.15 mm wide and maybe 0.4mm long. So small, but visible. About the size of this:

,

Yep, a coma on an average LCD panel. And that is where the problem is. One has got into my laptop and under my screen and it is sure to die. It is currently scurrying around at the far left of the screen and I’m considering a mercy killing before it wanders further across the screen into prime acreage. I had this before on my old laptop. In that case it died in the middle of the screen and for ever more has looked suspiciously like a coma, or single ‘quote’, causing me confusion when it falls on top of emails, word documents and…. code. It really was a pain when it came to code. Even now, if I use that old machine it sometimes catches me out. It can merge with a letter in new and exciting ways, to subtly change a word or command.

I’m obviously not alone, a quick web search threw up some other people complaining of the same issue.

And of course it is a common knowledge that “bugs” in computing really did start out as insects getting fried in the electronics and valves of the very first machines in the mid-20th century. I wonder if that is really true or just another old myth? James Higgins seems to think it is real and who am I to doubt him. He has a photo of the evidence after all.

Enrichment of the Code Monkey Environment April 15, 2010

Posted by mwidlake in Friday Philosophy.
Tags: ,
1 comment so far

In animal welfare there is a concept called “Environment Enrichment”. This is where you do things to make the life of the animal in captivity more enjoyable. Often it is centred on how you feed the animal – either hiding their food so they need to forage or presenting it in a way that better matches their natural behaviour . So, for example, you might take your gerbils out of their cage and then hide seeds and bits of fruit around the place {or get Ben Fogle dragging chunks of meat behind a Land Rover through the lion enclosure at Longleat Safari Park so the lions can chase after it}. Or you might buy some of that expensive, transparent, coloured plastic tubing that plugs together in little mazes – as Gerbils of course run around pink, blue and orange transparent tubes in the wild…

Where I am working at the moment, Environment Enrichment for the captives is achieved by relocating the coffee cups in the kitchen overnight. We all turn up in the morning and go up in little groups to play the “open the cupboards in random” game in order to track down the mugs. Never the same cupboard two days in a row – except occasionally just to keep us on our toes.

We also have several fruit bowls and someone occasionally fills them with a selection of fresh fruit. Of course, as we are Code Monkeys, the bananas are most popular. What most of my fellow inhabitants have not yet worked out is the occasional bonus cache in the pot that looks like a flower vase. It’s usually apples.

The best bit of the environment enrichment is at the end of the week though. 5pm Friday, with the gentle tick of cooling laptops and the gentle lowering drone of hard disks winding down, and the glow of the LCD sceens dimming, the oasis is opened. A bottle of beer or can of coke can be obtained and you all stand around and discuss anything but computers. Well, OK, maybe computers a bit, but they have to be non-work computers.

Relax with Good Security :-) April 14, 2010

Posted by mwidlake in Architecture.
Tags: , ,
1 comment so far

It’s nice to know that your computer system is very secure. It allows you to relax.

Is this because you feel confident that your data is protected and that your systems cannot be compromised by malicious actions?

Well maybe, but in my case, today (*), this is not why I can relax. Security is allowing me to relax as I’ve been locked out of my account at my client’s site and it is hard to tune SQL/review design documents if you can’t log on. It is a little bizarre that my account expired today as I know the date my account is set to self destruct – I filled in the relevant forms myself and simply had my boss sign them before I popped them over to the security team. Unfortunately, I can’t pop back over to them to jolly things along as I am now in a remote location (really, very, very remote!).

I just have to wait patiently for HR, Security and Management to complete the complex little Morris Dance they have to do to confirm I am a real person, need the access and have not recently been asked to leave {I hope I am not going to be asked to leave!}.

I’m not really complaining. Having worked for the NHS back in the late 80’s and early 90’s, I have shocking tales to tell, such as of taking home confidential patient clinical reports in order to play with “SQL*report writer” on my personal desktop, and similar stories about modern organisations in the private sector {well what do you know, person X owes HOW MUCH?}. So I am glad security is an order of magnitude better now. {No, honestly, it really is! No matter how bad you think things are where you are now, you should see the stuff I saw back then. These days, you at least have the ability to lock things down, if not the real-world reality.}

But, like all process-oriented things, it has to be designed to work well to be, well, effective. I got locked out of the same systems in a similar way just before Christmas. How many people are being paid a day’s wage to ring up the helpdesk and drink endless tea?

(*) I wrote this blog a while back. It might even have been before I had a blog. But a similar incident reminded me. Oh, and what was my reward for an enforced day being paid to drink tea and read a copy of “Oracle Scene”? Three days of working like a madman to catch up on that lost day. *sigh*. I did not get paid overtime.

Friday Philosophy – Are short Posts Better Than Long Ones? February 12, 2010

Posted by mwidlake in Friday Philosophy.
Tags: ,
7 comments

Maybe

Just a pointer to an update January 27, 2010

Posted by mwidlake in Testing.
Tags:
2 comments

This post is really just to highlight that I finished salvaging Yesterdays Post. If you found it of any interest before, go have a look at the end. If not, heck go look at dilbert. As funny as ever but BOY is that web site suffering from advertising hell and slow performance…

Update – I removed the link to the dilbert site because I went over to the site the other day and got one of those “Your PC is INFECTED” cons popping up in my browser. You know, the ones that tell you you cannotget rid of the infection without their software, but the only infection is their software. I could not get rid of it without shutting down my browser session (and yes, I have PC security software that is updated every day).

Follow

Get every new post delivered to your Inbox.

Join 159 other followers