jump to navigation

How Much Knowledge is Enough? June 13, 2009

Posted by mwidlake in Blogging, Perceptions, performance.
Tags: , ,
8 comments

I’ve had a bee in my bonnet for a good few years now, which is this:

How do you learn enough about something new to be useful when you are working 40, 50, 60 hours a week?

Another bee is how much do you actually need to know to become useful? The bee following that one is if you do not have enough time to investigate something, how do you find the answer? Buzzing up behind is to fully understand how something works, you often need a staggering amount of back knowledge - how do you get it? Oh dear, it’s a hive in my head, not a single bee.

I am of course in this blog mostly thinking about Oracle and in particular Oracle performance. I think that these days it must be really very hard to get going with performance tuning as it has become such a broad topic. I don’t know if you have noticed but nearly all the performance experts are not in their teens. Or twenties. And precious few in their thirties. Forties are pretty much the norm.  We {and please excuse my audacity in putting myself in such an august group}  have been doing Oracle and performance for many years and have stacked up knowledge and understanding to help us.

For me this issue was thrown into sharp relief about 4 or 5 years ago. I had become a manager and, although I was learning lots of other skills and things, when it came to Oracle Technology I think I was forgetting more than I was learning. Oh, I was learning some new Oracle stuff but it was at a more infrastructure level. The real kick of reality was going to presentations on performance and Oracle internals. At the end of the 90′s I would go along and learn one or two new things but knew 90% of what was said. By the mid 2000′s I would go along and know 50% , the other 50% would be new. Then I went to one talk and found I was scribbling away as I knew precious little of what was being presented. More worryingly, I was struggling with “How does this fit in with what I already know?”.  I just didn’t know enough of the modern stuff.

That was a pivotal moment for me. It had the immediate effect of making me start reading blogs and books and manuals again. It’s not easy to find the time but I soon noticed the benefit. Even if I learnt only a little more one evening a week, I would invariably find that knowledge helping me the very next week or month. I was back on the road to being an expert. {Or so I thought}. Oh, it had a long term effect too. I changed job and went back to the technical, but that is for another day.

But hang on, during my decline I had not stopped being useful. I was still the Oracle performance expert where I worked and could still solve most of the performance issues I came across. It made me realise you do not need to know everything to be useful and you could solve a lot of problems without knowing every little detail of how something works. A good general knowledge of the Oracle environment and a logical approach to problem solving goes a long way.

I actually started to get annoyed by the “attitude” of experts who would bang on and on and on about how you should test everything and prove to yourself that your fix to a problem had fixed itas otherwise it was just being hopeful. I thought to myself “That is fine for you, oh exalted expert, as you have time for all this and don’t have 60 hours of day job to do every week. Give us a break and get real. Most of us have to get the problem solved, move on and get by with imperfect knowledge. Doing all that testing and proving, although nice in a perfect world, is not going to happen”.

Yep, I had an attitude problem :-). I was getting angry at what I now think is just a difference in perception. I’ll come back to that in a moment.

I don’t think I am going to go back on my opinion that for most people in a normal job, there simply is not time to do all the testing and proving and you have to move on, Making do with received knowledge. It just is not an ideal world. However, we need the experts to uncover that knowledge and we need experts who are willing to communicate that knowledge and we need experts we can rely on. I am very, very grateful to the experts I have learned from.  

All the time on blogs, forums and conversations the issue of “how do we know what sources we can trust” regularly comes up. Well, unfortunately I think that if you do not have time to do the testing and learning needed to become an expert yourself, you have to simple chose your experts, accept what they say but remain slightly skeptical about what they say. Everyone makes mistakes after all. I would advise you only accept someone as an expert and rely on their advice if they are willing to demonstrate why they believe what they believe. Everything else is just an unsubstantiated opinion. 

But I’ve come to some conclusions about most of the above questions I started with.

  1. If you are judicious in choosing your sources, you can learn more reliably and easily.
  2. Even a little bit of more knowledge helps and it often comes into use very quickly.
  3. The hard part? You have to make that time to learn, sorry.
  4. Although testing and proving is good, life is not perfect. If you did (1) you might get away without it. But don’t blame the expert if you get caught out.

But I’ve not addressed the point about needing all that back knowledge to fully understand how something works. Well, I think there is no short cut on that one. If you want to be an expert you need that background. And you need to be sure about that background. And that is where it all has fallen apart for me. I started a blog!

I already knew you learn a lot by teaching others, I’ve been running training courses on and off for a few years. But in writing a blog that is open to the whole community, I’ve realised I know less than I thought. A lot less. And if I want to be a source of knowledge, an expert, I have to fill a lot of those gaps. So I am going to have to read a lot, test things, makes sure that when I believe I know something I’ve checked into it and, when I fix something, I know why it is fixed {as best I can, that is} . All those things experts tell us we need to do. And that brings me back to my perception issue. 

Those who I think of as the best in this field all pretty much give the advice to test and prove. And they have to do this themselves all the time, to make sure what they say is right. And they are the best as what they say is nearly always right. It seems to be excellent advice.

However, I think it is only good advice, as it is advice you can’t always take, because there is too much else to do. I think sometimes experts forget that many people are just too pressured at work to do their own testing, not because they don’t want to test but because you can only live so long without sleeping. 

Anyway, I said something foolish about becoming an expert. I better go and check out some other blogs… start reading some manuals… try out a few ideas on my test database.  I’ll get back to you on how I’m progressing on that one in about, say, a year or two? All those gaps to fill….

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.

Follow

Get every new post delivered to your Inbox.

Join 156 other followers