All posts by Stephen Darlington

Oracle Comedy Errors Home

Welcome to the Oracle Comedy Errors Page!

This page is dedicated to all those frustrating hours that you have to spend fiddling about with Oracle just to get it working as it says it does on the box.

These are just things that have happened to me and the projects that I have been involved in. To make a really complete Oracle Comedy Errors Page we need your input.

For those that have already contributed, there is always this page. It also catalogues the projects and Oracle software that I’ve used to build up this list.

Why is this page here?

There seems to be a great number of people who are only too eager to bash Microsoft, but only a few who seem to hate Oracle. Looking at their products, I thought that there must be at least a few sympathetic souls on the net. A quick search on HotBot and Altavista seems to indicate otherwise.

To rectify this shameless situation, I aim to produce, if not the first, then the definitive list of Oracle cock-ups and anecdotes. Naturally, I can’t do this all on my own; there are others.

I can supply the TAR numbers if you don’t believe me…

Content

Oracle Client Software Comedy Errors

Oracle Data Browser

Oracle Data Browser, part of the Discover 2000 suite, is one of the least amusing applications that Oracle supply. Not because it’s bad, but because it almost works…

  • Windows 95 has a ‘full screen drag’ feature (freely download-able from Microsoft‘s web site). If you load Data Browser you don’t. It suddenly stops working.
  • Now this is supposed to be a feature, but I’m not convinced. The word ‘Browser’ seems to indicate that it’s a read-only product. In fact a version comes with it that isn’t.

Oracle Data Query

Until we started really using SmartClient, we thought that Data Query, half of the Discoverer 2000 suite, was the lemon of the Oracle product library. That’s not to say that it’s good, just that after all that’s happened with Applications we’ve more or less forgotten a lot of the really annoying stuff. Lucky Oracle.

  • Data Query makes Windows 2.0 seem stable. Even in it’s 32-bit version.
  • It often magically moves the input focus to somewhere you don’t want.

About Oracle Comedy Errors

Credit where it’s due

I am unable to criticise a suite of products the size and complexity of Oracle on my own. There are a number of people that need to me mentioned. Remind me if I missed you out!

People

Thanks to Anna Brabants who nearly created the term ‘Oracle Comedy Errors’ and certainly did an almost continuous stream of abuse (not all of it at Oracle).

And thanks to the rest of the project team, who invariable love Oracle products as much as I do.

Thanks to the people at Oracle support who no doubt have to put up with a lot, and offer much amusement if only after the event.

Sources

I’ve been on a number of projects that use Oracle, however most of the tales have come from the first two. On these I was a DBA and developer and ended up spending much time on the phone to Oracle support.

The first time, we were implementing Oracle Financials and Human Resources using a Sun UltraEnterprise 1 server and Compaq workstations.

The server was running Solaris 2.5, with Oracle Server 7.1.6, Oracle Applications 10.6.1 and an incredibly large number of patches.

The Compaq P166 clients ran Windows 95, with SmartClient Prod 15. Then Prod 15.1. And then with a number of ineffective patches… You get the idea.

The second time, we were implementing a bespoke client-server application. The Sun Ultra 1 (and later Ultra 2) server was running Solaris 2.5.1 (2.6) with Oracle Workgroup Server 7.3.

The Compaq P133 clients ran Windows NT 4 and connected to Oracle using OLE Objects through Microsoft Visual Basic 5.

Since then I’ve worked mainly as a developer (often doing data-loads) on Oracle 8. Any 8i critiques come from developing my 8i on Linux HOWTO.

Software Project Survival Guide

Introduction

For many people here, writing software is, if not a job, then a hobby. Our enthusiasm is a double-edged sword. Our technical knowledge is usually much greater than people who just develop software for a living. This sounds like a big advantage, but it’s not as large as you would have thought.

Let’s have a look in ‘Software Project Survival Guide’ (SPSG) to see what Steve McConnell, famed author of ‘Code Complete’ and ‘Rapid Development,’ has to say on the subject.

The most relevant bit I can find is in chapter two. It’s a project survival test. Out of thirty-three questions, only one (28: “Does the project team have all the technical expertise needed to complete the project?”) is directly related to our ability to effectively code.

That can’t be right, can it?

Content

While you’re still reeling over the consequences of that last paragraph, I’ll slip in some of the dull things that the book has to cover and finish with some of the more glamorous stuff at the end when you’re brain is back in gear.

Some of the most important stuff is ‘management.’ Whether it’s planning, quality assurance, tracking what’s been developed so far or checking on the number of defects, it’s not the ‘techies’ that are the most important.

At first this comes as a shock, but the more you think about it, the more it makes sense. Unless you know what’s going wrong, you can’t fix it. Unless the complete design is documented a team can’t effectively write the software quickly.

Think about Linux kernel development. It obviously work well, but it’s not terribly optimal. The same bug might get fixed several times and there’s not a huge amount of up to date documentation so people have to dive in at the code. For free software this works fine — since the time is usually free, but if you have deadlines and are under contract to deliver a working product on time you’re going to lose a lot of money.

Good bits

McConnell takes the three hundred pages to explain these past two paragraphs in detail. It sounds very dull, but he has a clear, friendly style that makes it, if not entertaining, then not as dull as it might have been.

He splits the project into stages, explains in broad terms what they are and documents each one in more detail in the later chapters. It’s all very clear and logical leaving you in no doubt what stage you’re currently at and what you should be doing for the successful execution of it.

Bad bits

‘Code Complete’ is a book that just about everyone that writes computer programs should read. ‘Software Project Survival Guide’ does not fall into the same category. The book should be read by “anyone who has a stake in a software project’s outcome” according to the preface, but that is only accurate once you define the type of project it covers.

To cut a long story short, if you write software professionally you should read it. It’s probably more use to managers and team leaders, but you can be a better developer if you know the kind of things that need to be done. Besides, almost everyone will be in charge of people at one point and will need a broader picture than merely what the other modules do. (Well where I work that’s true, anyway.)

It covers projects that have a customer whether that’s an internal customer, an external client or people that buy shrink-wrapped software. What it doesn’t cover are software projects like Linux, massive sprawling projects developed because someone is interested in doing it. This is not unreasonable. Half the challenge in a ‘normal’ project is tracking whether you’re running to schedule. If you don’t have a schedule and cost target it doesn’t matter. However, maybe we could take a few hints from the book to ‘streamline’ the process.

Overall

Steve McConnell has done it again. I don’t think that it will go down as a classic like ‘Code Complete,’ but SPSG is an indispensable book for any developer that has any interest in the process and not just lines of code.

The facts

Author: Steve McConnell

Cost: ?22.49

ISBN: 1-57231-621-7

Buy this book from Amazon.com of from Amazon.co.uk.

What About Free Documentation?

Introduction

There’s a lot of free or open source software on the net, and much been written about both that software and the process that drives it. Eric Raymond, of course, is currently the main anthropologist although Steven Levy beat him to it and there are many others.

There is also a significant amount of free documentation. One only needs to take a look at the GNU web site (their definition of a free operating system includes free documentation) or the Linux Documentation Project to see that. However, there doesn’t seem to have been a “Cathedral and the Bazaar” for free documentation, or even anything similar.

That’s kind of what I want to do here, but I’m not going to go into as much detail. Instead, I’m going to write about my own experience writing free documentation (my Oracle 8i Installation Howto), the trial and tribulations, the ups and downs, the good times and the bad… You get the idea.

Starting off

I guess the first thing to note is that I didn’t write the HOWTO to ‘scratch an itch’ — I already knew how to install Oracle! Instead, I noticed that many people were having difficulties and that I was spending quite some time replying to the same questions on newsgroups and Oracle Technet. You could say that I wrote the document in order to be just as helpful but without being quite so intensive on my time! (So my itch could have been to save time.)

Another motivator was ‘to put something back into the community.’ Sounds a little pretentious, but it’s true. I’ve been using Linux since 1994 and, although an able developer, have never contributed any code to any free software. This was my chance! I suppose I naively thought that writing English would also take less time than C. As we’ll see later, that didn’t turn out to be the case.

I think that this is an important difference between free software and free documentation. No-one will ever write free documentation to “scratch an itch” (as Eric Raymond so eloquently put it). This takes away, quite possibly, the greatest incentive to create something and may explain why, generally speaking, text is very much a second class citizen to code.

Release early; release often

The first decision I really needed to make was tools to use. My first thought was to add a few new pages to the web site that you’re currently reading. And then I got lazy. I decided to base my new work on the then current Oracle HOWTO, which meant that I had to get to grips with SGML and the SGML-Tools programs. At this point I wasn’t thinking in terms of getting it into the Linux Documentation Project, I just wanted to get a head-start. Once I’d actually started, it didn’t take me long to figure out that the structure of the old document didn’t match what I needed and, more or less, started again from scratch. I did, however, keep the same tools.

Having just read the Cathedral and the Bazaar, I consciously decided to issue my document before it was complete. I quickly wrote the introduction, prerequisites and installation sections and added a number of place-holders for the remaining sections. I then announced it in a message to Oracle Technet and a couple of newgroups.

Very quickly I got some excellent feedback. People were asking for clarifications and new questions, and others were pointing out factual errors. As with software, I quickly added these fixes and thanked the contributers both by email and in the document itself.

I was very pleased that this approach worked. Normally I would have ‘finished’ my work before making any issue, but by releasing early I was able to help more people early on and elicit — I’m guessing here — more useful comments. (I figure that’s true because I think I’d be less inclined to contribute to a finished document than a work-in-progress.)

Maintenance

Around version 1.5, a couple of weeks after my initial release, it was more-or-less complete. All sections were filled in and I managed to complete a successful installation just by following the steps I’d written about.

The first issue was the people didn’t follow my advice — how dare they! Oracle is a big and complicated application and, even on Solaris, you just don’t change things unless you have to and you always use a ‘certified’ operating system. This is an alien mind-set to many Linux developers, who tend to thing “newer is better” and is not helped by all the weird and wonderful devices that you can connect to an Intel-based PC.

The first questions I received that deliberately weren’t answered in the HOWTO were problems with different distributions. People were trying to get Oracle running on just about anything with a Linux kernel!

I didn’t fancy wiping my PC clean and attempting the install with as many different distributions as I could find, I just didn’t have the time. Fortunately, the same community on the Internet that helped me complete my first version added to my knowledge base.

I started to add more and more detail to the HOWTO. If you’re using RH6 do this, with Debian do that… It seriously affected the “flow” of the document for everyone. Given my Oracle (conservative) background, this is just not a problem I originally considered.

When Oracle released 8.1.6 I made the decision that the HOWTO was for RH6 and Oracle 8i R1. It would make the occasional nod to later releases of both the database and the distribution, but fundamentally the focus would be on one version of Oracle and one version of Linux.

As a kind of half-way-house, I started to add extra pages to my website detailing some of the idiosyncrasies of different Linux distributions or newer versions of Oracle. I’m still not completely happy with this approach but I’ve not heard of a better solution yet.

Feedback

Having “completed” my document, what keeps me editing? If I’m writing software, my motivation is adding cool new features. Or maybe adding new stuff for other people and waiting for their praise?

As I mentioned earlier, things are very different for documentation writers.

I’ve got an awful lot of mail about Oracle and Linux since late 1999 when I first published the HOWTO. The email I get seems to have gone through a number of phases. When I first issued the document, I got an almost fifty-fifty split between “thank yous” and suggestions for improvement. Almost all was positive, constructive and friendly.

Without it I would almost certainly have stopped writing. At this point I suppose my motivation was to increase the ratio of thanks to suggestions. I turned a stream of emails into a challenge!

As the HOWTO started to get into wide circulation, the number of helpful suggestions started to drop and the number of questions started to rise dramatically. Some I saw as suggestions as I didn’t cover those details, but most were just from people who clearly couldn’t be bothered to read any further than the front page and my email address.

I can’t count the number of messages I’ve received saying “it didn’t work, what should I do?” (in as many words). How should I reply to that without being rude?! I’ve also received emails from people giving me their “root” password and other confidential details.

The next stage was when Oracle released a newer version and RedHat decided to go with a new version of GLIBC for version 7 of their distribution.

By this point, my motivation was mainly trying to reduce the number of messages I was receiving. Sure, I felt like being rude but I rarely was. I tried to answer all the most common questions in the document, but this point was definitely the low point. Although the updates were helpful, I was doing them for the “wrong” reasons, and the number of messages saying “thanks” had dropped to virtually zero.

More recently I’m only getting the occasional question. It’s difficult to know whether that’s because my HOWTO covers just about everything it needs to or because I’m just not promoting it as much as I used to or because the cutting edge in Oracle is now with 9i. Or maybe I was rude and people are too scared to talk to me..?

In conclusion…

If my original intention was to save time, it failed miserably. I’ve spend even more time replying to emails and maintaining the document than I would have done occasionally adding comments to discussion groups.

Towards the end of this piece I’m sounding very negative, but that’s a bad way to finish as generally speaking it has been very enjoyable. Getting a Linux distribution with your work on is quite a buzz and it’s always nice to get a friendly message or offers of free CDs and books from strangers.

Engineer or Hacker?

Eric Raymond would have us believe that everyone that develops software for fun is a hacker. I know that historically this has always been the case, but that doesn’t necessarily make it the right thing. All good, and bad, things come to an end.

I doubt that it will happen any time soon, but I think that ‘hacker’ is a term that should whither and die.

The first problem, and this is the obvious one, is the public perception of it. Yes we all know that hackers write code while crackers break into computer systems, but how many people ‘outside’ know that? How many professional software developers, i.e., those who do it just for a living rather than for fun, know that?

If even professionals don’t know the difference, how can the rest of the population have a chance?

Of course there’s always the fanatical wing, those that claim that we should hit the problem face-on. We should call ourselves hackers because we know that we’re right and that everyone else is wrong.

It’s actually a very politically correct way of doing things, but I remain unconvinced that it works. Richard Stallman continues to insist on the term ‘free software,’ even though most people find it more confusing than ‘Open Source.’ None of this is about changing ideals or opinions, it’s just about the correct marketing of the term.

The second problem I identified is much more subtle. What does the term ‘hacker’ mean? My dictionary defines it as follows:

hackvt cut, chop (at) violently;

It goes on, but that’s the important part. My objection comes from the lack of precision that the term implies. You get a program and violently cut and chop it around until, by chance, you get something out at the end that seems to work okay.

I hope you don’t develop software like that, I certainly don’t. Any half-decent developer follows a process, no matter how ill-documented. When you debug software you don’t just dive in adding ‘print’ statements all over the place, guessing where it goes wrong. Instead you make a hypothesis and test, modifying your original until you get a good idea what’s wrong, then you start with the ‘print’ commands or your debugger.

Does that sound uncontrolled and violent?

All that planning and precision, all the experience that it takes to be able to make a reasonable and accurate hypothesis sounds more like engineering of some kind.

And that it why I call myself a Software Engineer rather than a hacker, even when I write code in my spare time.