jump to navigation

Friday Philosophy – Simply Complex July 24, 2009

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

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: ,

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}

The Knowledge Curtain. June 8, 2009

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

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.

June Management & Infrastructure meeting June 5, 2009

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

Wednesday this week saw the first UKOUG Management & Infrastructure meeting special interest group meeting (MI SIG) of the year – postponed from April due to a clash with the G20 summit. You can see details of the meeting here where {if you are a member of the UKOUG} you can download some of the papers.

I feel the MI SIG has been struggling a little over the last few meetings – too many sales pitch presentations and numbers hit by travel woes (we just fell unlucky) and then the recession – but this meeting felt better. We had a good mix of strong presentations and numbers were up. The number of expected delegates has been very variable over the last 2 weeks, at one point we were full (50 people) but then some dropped out, others registered late. We ended up with 39.

At the last meeting I asked if people wanted more on the management side and the majority did, so I pitched a presentation about how to be a Manger in IT. It would have been relevant to management in other disciplines but IT does have some unusal aspects, one being that there is a much higher percentage of introvert and logical personality traits amongst IT people. Soft Skills and considerations of personality do tend to get short change in technology environments too.

Not only did I pitch a touchy-feely topic but I also went powerpoint-naked. I put up a half dozen intro slides and then turned off the projector and just talked. I was more than a tad anxious that this could have fallen flat and ended up as me spewing random drivel from the front, but the audience took up the topic and started chipping in. It snowballed and became a general discussion. I managed to keep it flowing and mentioned most of the things I wanted to include and also took a lot of input from the audience. Maybe one or two of the links I made to add my intended points were a bit tenuous but heck, it was the first time I’d done a free-form presentation like that for years and years.

Not only was the session a success {phew} but it seemed to set the pattern for the rest of day. We had had some good questions being asked of John Nangle during his opening presentation on Exadata (I’d really like to get my hands on one of those units) but after the free-form session everyone seemed to be talking to each other more and all presenters had questions and little discussions to deal with during their sessions. They all dealt with them well.

We rounded off the meeting with a drink in a local hostelry for those who were inclined and the discussions kept going. The general feeling was that it had been an excellent day with people being a lot more interactive than normal. I know other SIGs use “speed chatting” and other things to help encourage people to talk to other delegates. They have found that such things might not initially be popular {what! you want me to talk to strangers?} but always give the meetings a greater feeling of interaction and delegate feedback is that they are {sometimes reluctanatly} recognised as helpful.

I think I’ll try and have some sort of interactive or ice-breaking aspect at future meetings as it seems to really help the day be a success.

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.


Get every new post delivered to your Inbox.

Join 206 other followers