jump to navigation

Friday Philosophy – CABs {an expensive way to get nowhere?} March 11, 2010

Posted by mwidlake in biology, development, Friday Philosophy, Management.
Tags: , ,
3 comments

A few years ago, my wife and I went to New York for a holiday. We got a cab from the airport into Manhattan. It was an expensive way to see, at great length, some of the more uninteresting automobile transit routes through New York. We arrived at our hotel a great deal later than we anticipated. And with a lot of our paper dollars no longer in our possession.

I’ve also taken cabs through London, usually at the weekend to get back to Liverpool Street Station. The trip is generally quick, painless and not too expensive, no matter what bit of London is currently being dug up. Those black-cab drivers know their stuff.

Of course, the CABs I refer to in the title of this Friday Philosophy are not private cars for hire. In this context CAB is Change Advisory Board. A term that can make grown developers weep. If you do not know, the Change Advisory Board is a group of people who look at the changes that are planed for a computer system and decide if they are fit for release. My personal experience of them has been similar to my experience of the taxi variety, though sadly more of the New York than London experience.

You might expect me to now sink into a diatribe {ie extended rant} about how I hate CABs. Well, I don’t. CABs can be a part of a valuable and highly worthwhile process control mechanism. Just as proper QA is core to any mature software development process, so CABs are important in getting informed, talented stakeholders to review proposed changes. They check for overall system impact, clashes with other proposed changes that individual development streams may be unaware of, use their own {hopefully deep and wide} experience to consider the changes and to verify Due Diligence has been invoked {that last one is a bit of a minefield and where, I believe, many CABs fail}.

Sadly, though this is often the aim, the end result is too often a bunch of uninformed and technically naive politicos trying to wield power, using the CAB meeting as an extended game of management chess.

I’ve seen CABs trade changes. “I’ll let you have X if I can have Y and Z”. I’ve seen CABs turn down changes because the form had spelling mistakes in it. I’ve seen CABs object to a change that will save the company 5 million pounds a day because it lacked one signature.

That last one just stopped me in my tracks {I’m not exaggerating either, if anything I am underplaying the cost impact of that decision. I saw the figures and I wasted a couple of days of my life checking, 5 million pounds a day was the least I felt I could prove.} We are talking about enough money every day to pay the salary of everyone on the CAB for several years. And they blocked it because the DBA team had not signed off the change. No effort was made to address the lack of the signature in any way, the change was just refused.

The DBA Team had not signed off the change because the one and only DBA Team Leader who was allowed to sign off was on holiday for two weeks. They needed that holiday too, for other but I suspect linked reasons.

Now, I knew the DBA Team Lead and he was a good bloke, he knew his stuff and he was not paid 5 million pounds a day. His deputy was paid even less but was no less talented but she was not allowed to sign off the change as she was not the DBA Team Lead.

That was a CAB gone very wrong. The process of the CAB had been allowed to over-rule good business sense. It was also overruling general and technical sense, but that really is secondary to what keeps the business making a profit.

I’ve seen the opposite of course, technical teams that just apply whatever changes they feel are fit, with no oversight or CAB. To be honest, this less controlled process seem to mess up less often than a poor CAB process as the technicians know they are the ones who will spend the weekend fixing a mess if one occurs. But that mess up will occur eventually, if control is lacking, and the bigger and more complex the IT environment, the greater the chance of the mess up.

So, I feel CABs are good, no make that Great, if you have the right people on them and you have a sensible cascade of authority so one person being away does not block the system. That is quite a bit harder to put in place than a simple “Dave A, John, Andrea, Alex, Raj, Dave P, Mal, Malcolm and Sarah have final signoff” which most CABs effecively become.

But there is one last fault of CABs I want to highlight. They tend to treat all changes in the same way and all changes are not the same. Upgrading the underlying OS is not the same as adding a cardinality hint to one Business Objects report.

If your CAB or change process treat the two above examples the same, then your CAB or change process is broken. Now, in all IT “rules of thumb” there is an exception. In this case, I am truly struggling to think of one. My feeling is that if your change process treats an OS upgrade the same as adding a hint to a report, it is not fit for purpose.

Those are my main issue with CABs. They should be of significant business importance, but nearly always they are implemented with one process to deal with all situations and then get taken over by people with an “Office Politics” agenda as opposed to a “Getting the best job we can reasonably expect done” agenda.

I’m very passionate about this and I have a way I hope can throw this issue into context, an analogy.

Ask yourself this senario.
You go to your doctor with a niggly cough you have had for a week OR you go to your doctor because you almost passed out each day you got out of bed for the last three days.
If your doctor treated you the same for both sets of symptoms, would you be happy with that doctor?

Why are all IT changes handled by most CABs in exactly the same way?

(BTW if you ever almost collapse when you get out of the bed in the morning, do NOT go to work, go instead to your doctor and ask them for a full medical and if he/she does not take blood pressure readings and order a full blood chemisty test, go find a new doctor.)

Making Things Better Makes Things Worse February 11, 2010

Posted by mwidlake in development, Management, Perceptions.
Tags: , ,
12 comments

This could be a Friday Philosophy but I’ve got a couple of those lined up already. Anyway, I am suffering at work at the moment. I’m encountering a phenomenon that I have talked about with Dennis Adams a couple of times. It probably has a proper term, but basically it is the odd situation that when you make things better, you get more complaints. {Dennis, do you know the proper term?}

{Update. Dennis was good enough to link to this paper he wrote on customer feedback}

Anyway, Let me explain. You have an application sitting on a database. The screens are slow, the reports take an age to come out, your might even have considerable system instability and unplanned outages. The users are not unhappy. They were unhappy last year. Now they are just cynical and they just expect the system to be slow, unresponsive, flaky. So they do not report any problems.

Then things change. The system gets some much-needed care and attention and now the slowest reports get tuned up, the screens come back faster and less spontaneous department-wide coffee breaks are caused by the system crashing. Everything gets better. But not for the help desk, now they start getting calls. “This report is too slow”. “Why can’t I jump straight from the customer screen to the pending orders screen?”. This happens because the users now realise that something can be done. There is a point in complaining as there is a chance their piece of misery could be made better. I certainly went through this many years ago when I inherited a system that crashed every week. No one mentioned it, they just went to tea and complained about it. The first time it crashed after I arrived I could not believe that no one had called before I had realised it had died. Once it had been up solidly for a couple of months, then when it crashed boy did we hear about it!

Also, when you improve a system and things generally get better, occasionally something will improve and then fall back a bit. Hardly anyone says “thanks” for the initial improvement but they will say something if it improves and then drops back.

That is what is happening for my main client at the moment. The system was not that bad, but it needed some help. Why else would I be there? I’ve been beavering away with the rest of the team and we are making things better, so far mostly at an underlying “getting the overall system straight” level. A new chap has joined to help concentrate on performance and he is really making inroads into specific things, individual reports and processes that need a good sorting out.

So now that things are getting better and performance is generally improving, anything that is still slow is being brought up by the development and support teams. Also, we’ve made a few things slower (I’m sorry, it just happens like that) and they certainly get mentioned.

So, I’m busy. And I could get annoyed at people asking why X is slower when Y and Z are faster. But I don’t, because Dennis explained this counter intuitive theory to me.

I know things are getting better as people are annoyed as opposed to apathetic :-)

Friday Philosophy – What Was My Job Again? December 11, 2009

Posted by mwidlake in Management.
Tags: , ,
2 comments

How much control do we have over what job we are in?

I know I have mentioned this before, but I did not choose to work with Oracle – I fell into it by accident. I found myself in a job which I was no longer enjoying, for a boss who had issues with me and I had issues with a salary (mine, of course). So I decided to apply for a job with a company a friend of mine worked for:

For those of you who are not UK-born or have seen less than three decades go by, in 1990 “Oracle” was a teletext company that provided information on your TV screen for the TV company Channel 4. Basic news, entertainment, sports etc via chunky text and chunkier graphics thrown up in glorious low-res.

I honestly thought I was going for an interview with that company, as opposed to the other “Oracle”, some database company with the same name which went on to pretty much conquer the corporate database and applications world. That was a pretty lucky break for me and I made a conscious decision to stick with this database stuff.

Many years later I was on a contract doing database performance tuning. Someone, a manager, came and asked me about how they could save space, not in the database world but in the Unix filesystem world. So I made the suggestion that they check out the man page on compress. We compressed some big files and he went away happy, leaving me to get on with my database stuff. My big mistake was, when he came back a week later and asked how he could get the compressed data out, I promptly showed him. I revealed too much knowledge.

I came in to work the next Monday morning and my desk had gone. There was an oblong square of dust and hula-hoop crumbs, nothing else. Even my pile of “documents to get back to” from under the desk was gone. Had I been sacked? No, I had been put in the Unix system administration team. My desk had been picked up and physically moved across the room to the Unix Corral, along with everthing on, under or next to it.

No one has asked me, it had not been mentioned to me at all, the managers had just realised on Friday that half the existing team (contractors) had left at the end of the week and no replacements had been found. That devious manager I had helped had told the others I was a whizz at Unix and so my fate was sealed. I was not a whizz at Unix, I was barely competent at basic shell programming. But I learnt a bit before deciding I wanted to stick at the Database stuff and went off to a contract doing that again. I still kind of wish I’d done the Unix a little longer though.

The final shift I’ll mention, and is probably more commonly echoed in other people’s experience, is coming in one day to find you are a manager. This had happened to me small-scale a couple of times, taking on a contract where I ended up in charge of a team, but in this particular case I was a permanent employee managing a team of 4 DBAs and my boss left. Within the week I found that I was being treated as the manager of 5 or 6 teams, totalling about 30 people. More by them than by upper management, but upper management cottoned on and asked me to do the job. Long story cut short, I resisted the move upwards but it happened anyway. Not, at that time, what I wanted at all.

I’ve told the above story a few times when doing presentations on management-related topics and many people, a surprising number to me,  have said to me afterwards that the same sort of thing happened to them. I am also now chair of the Management and Infrastructure Special Interest Group of the UK Oracle user group. That SIG is full of people with a similar story.

What is the point of this particular Friday Philosophy? Well, these experiences have made me realise that a lot of people are probably doing jobs they just found themselves in, or in the case of managers, just got pushed into.

If you did not chose your job, you are unlikely to be a good fit, especially to start with.

I’m sure most of us have experienced this and, looking back, can see that initially we lacked the skills, the background, even the inclination for the role. But we either got on, moved on, or become morose and bitter.

This also means that we are all probably encountering a lot of people in that exact situation, all the time – People doing a job they just found themselves in. So, if someone seems to not be doing a job as well as they could, check how long they have been doing it. If it is a recent change, remember your own experience and cut them some slack. You would have appreciated it when you were them.

It also explains Morose and Bitter Geoff who manages Accounts too, doesn’t it?

Friday Philosophy – Simply Complex July 24, 2009

Posted by mwidlake in development, Management.
Tags: , ,
3 comments

Piet de Visser is an ardent champion of simple solutions within the Oracle arena – and I completely agree with his outlook on this. {Almost}.

Simple solutions usually win long-term as they are easy to understand, easy to look after and easy to change. OK, you may not be getting the absolute best performance you can, you may not be doing the job as completely as you can, but if it is a simple solution then you probably implemented it easily and quickly. This probably also means it cost you not-a-lot in person time and brain power, so you can personally afford to blow it away and do it again. In fact, with all that saved time, money and brain power you can probably afford to create a couple more simple solutions to other problems to.

Perhaps the only thing you are probably losing out on is the kudos of having been smart enough to come up with something very cunning and complicated, to impress everyone with. You’ll get over it, people don’t stay impressed for very long, especially when your mind-bendingly cunning and complicated solution melts into a heap {as a couple of mine have, ho-hum}.

Is your chosen solution simple? I give you a simple test – Explain it to someone.

  • If you can explain it to your colleagues, it is probably quite simple. If you can’t, either the solution is not so simple or your colleagues are.
  • If you can explain it to your boss then it is probably an excellent example of simplicity.
  • If you can explain it to your mum, you have blindingly clever simplicity and your work here is done.

Oh, you remembered that I said I almost agreed with Piet.

I can think of four reasons for not implementing a simple solution. I have listed them in ascending order of being a good reason (best last). And, unfortunately, also descending order of likelihood (most likely last).

  • You were sold a complex solution as complex solutions earn the vendor more money.
  • You needed to impress someone with your incredible technical skills {this could be your peers, quite often it is your boss, but for most of us it is usually ourselves, let’s be honest :-) }
  • You really do need to do something complex for a very valid business reason, like 99.999% availability {eg for that system people can ring up as they have a cough but are convinced they are dying of “swine flu”}.
  • you are creating a generic solution.

What do I mean by the last point? I mean that your one solution has to work for a lot of different situations or usages. The system has to work for a large range of inputs or do a lot of things.

The whole Oracle database  is {in my opinion} a generic solution. A vast and complex one to be sure, but it is intended to work for a little database on a desktop keeping track of the parts in your workshop, an integrated system in eg medical or scientific robots keeping track of thousands of samples, vast data stores of telephone calls so you can do your bills, huge on-line web-based shopping systems, a front end to image or video stores.., the list is a big one. You might need a little Oracle database to hold the list in.

With version 10 Oracle Corp made a big thing about the database looking after itself .  The database was a generic, self-managing, handle-anything solution and you would not need those pesky DBA types to keep the beast working for much longer.

That is why it is so complex and, not matter how much some of us complain {as I myself often do}, it has to be and it is getting more complex with every version. I’ll take my current favorite topic, stats gathering, as an example.

Back with the rule based optimiser, you had a set of rules. 15-16 I think {I’ll let you lot check – google “rule based optimizer oracle -burleson”}. You learnt the rules, understood them and you were home and dry. Except that the RBO could not cope with data-specific oddities, how different access methods were better for different table sizes and index specificity.

So Oracle added statistics and the cost based optimiser. To make use of the cost based logic a load of mathematical calculations and considerations had to be added (and continues to be added), based on statistics you had to collect at the right time and the right level and many sites did not. People complained the CBO “just did not work”, which it did not if you didn’t collect the stats {and sometimes even when you had} but it was doing a lot to cope with a wider range of systems automatically. Histogram stats now allowed skewed data to be coped with, in most situations. 

So they introduced a job to do it for you but it had to detect the right level and type of statistics to gather on all objects, be they tiny tables, massive tables, tables with skewed data, indexes, global indexes on partitioned tables… And yes, once again, it is another complexity you have to get to grips with if it does not fit your particular system demands.

I’m sure you can argue with me over the details, but I think I’m making a valid point that every time a system {be it Oracle or an O/S} is modified to cope automatically with more senarios, it becomes a more complex system. You need a DBA with several manuals welded to their brains to get the best out of this thing now, not less as claimed back at 10’s release {did they make the same claims for 11? I was too busy keeping systems running to really notice at the time}.

Maybe the answer is to stop using generic systems like Oracle and swap them out for a mixture of spreadsheets, MySQL-type simplistic databases, netezza-type systems for datawarehouses, hand cut ‘C’ applications for handling image stores, JAVA apps and flat files for web sites…Only you are going to have to learn how to use all those things to create all the systems you need to create.

You are only going to manage this if you create those dozens of systems as simple ones.

Fuggles was very simple. The lights were on but nobody was home. But that was fine as all she wanted was to sit on you and be scratched.

Fuggles was very simple. The lights were on but nobody was home. But that was fine as all she wanted was to sit on you and be scratched.

COC – The Chain of Optimistic Communication July 1, 2009

Posted by mwidlake in Management, Perceptions.
Tags: ,
3 comments

Well, after the very long, technology-based post of yesterday, a smaller one today, on a management theme.

I came up with this concept of the Chain of Optimistic Communication about a year ago, in one of my presentations on disasters. As a potential disaster, I’ve converted the relevant PowerPoint slides into a Flash movie. This is the flash movie. The second slide is an animation of what the Chain of Optimistic Communication is, the rest is some thoughts on it’s impact and how to avoid it.

{If the flash movie fails and you can read PowerPoints, you can download the
PowerPoint here}

{And another thing, It’s my first Flash attempt, I know the page numbering is duff, I know the layout is a little off, I might fix it when I have had some more sleep}.

If you can’t be bothered with the Flash movie {go on, it’s more fun than reading stuff!}, this is what the Chain of Optimistic Communication is:

  • You, the worker at the coal face are asked by your boss how the development of the new system is going. You tell your boss that it’s not going well at all and you list 3 things that have not been done, one that has been done and one that is partially done. You don’t mention that the partially done one you plan to do tonight, fuelled by coffee and whisky.
  • Your boss tells their boss that progress is being made, half the tasks are in hand but they “need to proactively re-address a resource mismatch or two”.
  • This top level boss tells the VP of development that all is in hand, resources are in place and all bases are covered, but more budget for planning would be wise. 
  • VP of Development reports to the board that the latest Agile development using cross-skilled resource pools is on track to deliver the milestone implementation. Or something.

ie all levels lie, ever so slightly optimistically as they communicate up the management chain.

As a result, the higher the manager, the more rosy the picture and the more out of touch they seem to the worker at the coal face.

When I presented this idea, I got a surprisingly positive response from the audience. It was the most common thing people talked to me about after the presentation, so I guess it struck a chord. Or else it was the point in the presentation when the sound of the caterers dropping a try outside woke them up.

Another side of the Chain of Optimistic Communication is that the higher the manger, the more they are led to believe all is OK and the more often, it seems to them, that apparently “under control” projects flip to become disasters when the rosy white lies have to be ditched when the reality becomes so grim. Often with no warning. No wonder managers get so many heart attacks and strokes.

 

{This is me just trying to get the flash movie to play with my website headers, it will disappear in a couple of hours flash movie}

Unhelpful “helpful” people June 9, 2009

Posted by mwidlake in Management, Perceptions.
Tags: ,
11 comments

I keep meaning to getting back to more technical blogs but I need to spend some time sorting it out first, and something has just bugged the hell out of me, so another “wordy” one today.

Richard Foote has gone back to explaining the basics of indexes and the CBO, which if you are new to CBO or indexes, hot-foote {sorry} it over there immediately and check it out. He is a brilliant teacher.

Near the start, he has a link to someone on one of the OTN forums who is stating the Cost Based Optimiser sucks. I won’t repeat the link. No, sod it, I WILL repeat the link. Here it is. It might elevate the page in google’s scoring but what the heck.

This person’s rather poor outlook on the CBO did not bother me, nor the fact that he is, in my opinion, wrong {he suggests using the rule hint on oracle 10, which is an option but is not, in my opinion, a mighty good idea as (a) who now knows the rules of the Rule Based Optimizer and (b) the hint will be ignored if you are using most new features added since 8, such as bitmap indexes or IOTs or partitioning. It might {and I have no proof for this} cause the feature not understood by the RBO to not be used, so maybe ignoring a nice bitmap index or function based index. Oh, and (c), if you have good stats the CBO usually wins.}.

What irritated me was his/her high-handed and abusive posting. That really annoys me. Then I thought “no, we all lose our temper sometimes and the person they are having a pop at did kind of ask for it”. But because I think that being abusive or condescending on forums is such bad behaviour, I dug a little into the other postings by this person.

Some were helpful. Many were simply links back to other pages or to some front end to Google the person’s question. And several, many, were abusive. Along the lines of “Why are you so stupid”; “If you can’t be bothered reading the manual you don’t deserve help”; “I would not employ you as you are a moron”. You get the idea?

It is a big problem with forums, and actually also in the work place (and occasionally, sadly, at meetings and conference). People being condescending, antagonistic and demeaning to others who do not know what they, the Mighty Brain, knows, who seem to Mighty Brain to not be trying quite as hard as they could or are seemingly asking something obvious.

OK, if it is obvious, give the answer. It might be that you, oh Mighty Brain, did not understand the question. OK, they maybe are not trying hard enough. Suggest to them where they could look, maybe this person has 3 managers breathing down their necks and they just really, really want an expert opinion now as they are not sure which of the seven opinions in google to trust. And Mighty Brain, unless you were born with your knowledge placed in your head by God, as a special force on this earth, you didn’t know what this “moron” does not know at one time. Someone told you or, vary rarely, you worked it out for yourself.

The truly, blood-boilingly, unjust thing about Mighty Brain? They are so sure of their own towering knowledge that they can’t see that they are often wrong.  I can’t think of any Oracle Expert who is widely accepted by their peers who is a “Mighty Brain”. In fact, a common trait of the very best practitioners and teachers (of any subject, not just IT) is that they are always willing to admit they do not know and to learn.

I did look for a way to ask for this particular Mighty Brain to be barred from the forum, but then I just decided to vent my spleen on my blog and have a glass of wine.

I hope that person trips over and really cracks their shins or something. Nothing permanent, just something incredibly painful. Grrrrrr.

Update – Jonanthan Lewis has commented to let me know that this “unskilled and unaware” {what a brilliant phrase} is the Dunning-Kruger effect. The link got filtered out by the comment mechanism, so I’ve posted it {well, maybe a similar one} here. Thanks Jonathan.

The Knowledge Curtain. June 8, 2009

Posted by mwidlake in development, Management, Perceptions.
Tags: , , ,
5 comments

I came across the concept of “The Knowledge Curtain” in the late 90’s, from a man called Lee Young, who I worked with for 2 or 3 years, along with a friend Mike Cox, who was key to showing me how to peek through the curtain.

The below is taken from a powerpoint presentation I sometimes give on project disasters (how to avoid, not how to encounter!):

When systems designers talk to end users, both parties usually end up not really understanding each other

When systems designers talk to end users, both parties usually end up not really understanding each other

The basic principle is that, the knowledge of your users/customers is partly hidden from you. When you ask people for whom you are designing a computer system about their job, they don’t tell you lots of stuff.

  • Things that they assume you know.
  • Things that it does not occur to them to mention.
  • Things that they do not want to admit to doing as it sounds silly or badly managed.
  • I’ve even had people not mention parts of their job as they don’t want their manager knowing they do it.

But that is OK, when you talk about information technology and computer systems to them, they have exactly the same problems with what you say :-).

Lee’s presentation, with N. Mehandjiev, predated the all-encompasing rise of the internet and this is one of the few references to it I can find. {Among the relatively few other hits on the topic, amongst the ones about knowing how to make curtains, are references to the “Knowledge Curtain” as the concept that the Web is not as available in other areas of the world. A related but very different issue}.

So, how do you peak beyond the knowledge curtain? Systems designers and developers with experience learn how to ask the questions “what are the exceptions to what  you have just told me” and “what else do you do” in many, many ways and without giving offence. After all, you have to keep asking these two questions and people naturally get irritated with that and some feel you are suggesting they are either stupid or lying. It can be tricky. 

I think that unless you have someone who is fully IT literate and has done the job the computer system is to assist with, you will inevitably only catch a part of the requirements.

For massive projects over many months or years, I think this lack of a clear understanding of what people do is a major factor to their failures. This is made even worse when the analysis is done by one group of people and the specifications are then shipped out to an external party for the application to be developed. With all that missing knowledge, it is no wonder some systems are initially so poor.

I only know of one method that reliably allows you really see beyond the knowledge curtain. That is prototyping and user feedback. Only when you show the people who are going to use the system what you have put together to help them will they know if it works. These sessions are incredibly valuable and only in development projects where they have been key to process have I seen the project deliver something truely useful.

I now have a general way of developing anything.

  • I ask the users for 3 or 4 major things that they want the system to do.
  • I develop those 3 or 4 features as quickly as possible and show them to the users.
    • One will be almost exactly what they need.
    • One or two will be close to what they need.
    • One will be utterly useless.
    • During the above, one or two critical new needs will come up.
  • Fix the close ones, dump or redo the useless one and add the new needs to the list.

Simply cycle around the above, asking for new features when you have got less than 4 features you  are actively working on. And only polish features (add all the nice screen touches and widgets) once is is exactly what they need or pretty damned close. {You hardly ever run out of features before you run out of time and money!} You end up with an excellent system that evolves to better help the customer as time goes on.

There are lots of development methodologies that have the above principle (or a variation of it) as their core, so I am certainly not the first person to find that this method works. Which is why I find it difficult to understand why so many projects don’t use it?

BTW, I thought I would just add that one of the factors in my starting a blog was a comment by Andrew Clarke on his, several years ago before Blogging really took off. It was for a presentation I did which included the Knoweldge Curtain concept. He was very nice about my presentation and I still appreciate it. This is the link, but as it is an archive you will have to search for my name.

Fear of Databases May 29, 2009

Posted by mwidlake in Management, Perceptions.
Tags: , ,
4 comments

“It’s all in the database!”

I’m sure most of you (if you are in the UK, I must remember that the web is a world spanning medium) have seen the adverts by the wonderful TV Licencing authority or the DVLA. If not they go something like:

“We keep records” {background music}
“We know if you have paid…or not.” {Music become more sinister}
We will find you, you cannot hide” {more affirmative music}
“It’s all in the database” {doom-laden musical flourish}

OK, maybe I lay it on a bit with the music.

Now, as a database professional, I see “it’s all in the database” as a good thing. With luck it will be a well designed database with referrential integrity and all nicely validated.

Nearly all news media stories about actual or perceived threats to electronic privacy also site “The Database” as the core.
“They {who?} will hold all your web searches in a vast Database”.
” A laptop holding a Database of 1 million double glazing customers has been stolen”. I bet it was actually 10 thousand and in a spreadsheet.

It’s getting to the point where I don’t feel comfortable telling people I meet outside of the IT world that I am a database expert. Databases are hardly ever now seen in a good light, they seem to be linked only to things bad and Orwellian.

The Database is also often cited when companies get things wrong for their customers. You ring up to complain about some aspect of non-service and are often told “Oh, it doesn’t agree with you in the Database” or “the Database has got it wrong”. No it hasn’t, the person putting the information in the database got it wrong. I’ve been in the unusual situation of being told a lie where the database was given as the cause but I had access to that database. So I checked and the database was fine. It was being used as a convenient and much maligned excuse.

Very little is mentioned of the beneficial uses of databases.
For most of us our salary is processed via databases and it is a lot cheaper and more reliable than having half a hundred pay clerks doing it manually in pen and ink.
Databases are used to hold or index much of that vast quantity of stuff that you can search for on the net. Even the useful stuff on Klingons.
I for one would welcome a UK-wide database holding my basic medical details so that when I go to my GP or hospital, they do not need my memory (and in fact my consciousness) to tell them my medical past. If I have an allergy to a common drug I damned well want all medical people to know that before they put 10cc of the stuff into my veins.

And to wrap up my bad-tempered tirad, I now find it particularly tricky to talk about what I still feel is my most significant achievement in IT, namely an 80TB Database of genetic information. Without getting into the topic of Bioethics, which is beyond the scope of this blog, Genetics and a lot of biological stuff is now painted grey, if not deep, murkey, scary Red by the media. I tell John down the pub that I created a huge genetics database, he is sure I am either working on a secret government project to know all about his inner workings or some evil company combining tomatoes and monkeys into some awful, new thing that {and he has seen the movies to prove this} in all likelihood will turn into a zombie killer, escape and do for mankind.

Maybe I’ll just tell people I shoplift for a living, it might be more socially acceptable than being involved in Databases or Genetics.

Management And Infrastructure SIG May 28, 2009

Posted by mwidlake in Management, Meeting notes.
Tags: , ,
add a comment

It is the next Mangement and Infrastructure Special Interest Group meeting next week (MI SIG), on Wednesday 3rd June.

I currently chair the MI SIG and, just as Andrew Clark says about the Development and Engineering SIG, “it is not as sexy as it sounds” {The chairing, I mean, the SIG itself is incredibly sexy and wonderful}. It basically means I spend a few days 2 or 3 times a year helping organise the event, strongly supported by the UK Oracle User Group (and in particular by Michelle Ericsson) and by the deputy chairs, Gordon D. Brown, Neil Chandler and Tony Clements, our “Oracle buddy”. I then chair the meeting itself.

Chairing may not be sexy, but it is rewarding, especially when we get a good line up of talks as for this one and the registered delegate numbers are healthy. SIGs have been suffering poorer attendances of late and a high number of delegates just not turning up, which is vexing (and, I’m sorry to be blunt, bloody rude to the speakers and committee who do this for free).

I’m presenting on “Being an IT Manager” and I am trying something different. I am ditching Powerpoint and I am just going to talk. It could be a disaster.

I’ll of course let you know how it went. Alternatively, if there are still spaces, come along and witness for yourself.

Why Tune? May 27, 2009

Posted by mwidlake in Management, performance.
Tags: ,
add a comment

I’m just wrapping up a couple of changes to a presentation I am putting on the UKOUG web site. Right at the start is a slide that sums up my attitude to tuning. I might make it my tag line but for now, this simple post will do (before my brain drops the information, as it has a talent for doing)

If you are not tuning something in order to help your business (or client) achieve something faster that they need to achieve faster, then you have to question why you are doing it.

If it is to learn HOW to tune, that’s good.

If it is just to see if you can get it faster, for the crack as it were, then if there is anything as or more important than making a cup of tea to be done, you should be doing that.

Follow

Get every new post delivered to your Inbox.

Join 163 other followers