Tom Kyte has a pretty cool job. He gets to fly around the world chatting about something he knows a lot about and which he finds infinitely fascinating. Kyte’s official job title is senior technical architect in the Oracle server technology division. But really he is a kind of Oracle gunslinger, able to shoot down problems that crop up in the wild frontiers of its database.
They didn’t just hand him this job. He earned it by answering thousands of questions. It began in 1994 when he used to start the day by surfing the fledgling internet looking for interesting questions in the Oracle user forums and trying to answer them. As he explains it, some people fill out crossword puzzles in the morning “to get their brain working”; he likes to solve database problems.
By 2000 Kyte had dealt with 12,000 questions and developed a reputation as a go-to-guy for company database solutions. Oracle magazine asked him to publish some of the question and answers in a column and this soon migrated online to become the AskTom website, which celebrated its tenth anniversary in May this year. Kyte says he has published answers to 12,000 queries, but there have been about 36,000 questions submitted and most are answered offline.
Although he has the ability to “phone a friend”, Kyte deals with most of the questions himself based on his years as a specialist. He says this is unlike today’s developers who have to be proficient in a multitude of applications and operating systems.
At his presentation in Auckland to around 100 developers and database administrators Kyte made the intricacies of the Oracle database sound epic. The title of his presentation was “What are we still doing wrong?”. According to Kyte, quite a lot, but here’s some of his key concerns.
Kyte says that every time you alter a piece of code there are consequences. And often what might appear – at least to the business – to be simple changes can have unintended consequences, producing ripple effects that might alter hundreds of millions of lines of code (see sidebar ‘If you think it’s tough…’).
“There is no such thing as a small change; everything is a lot more complex than it sounds. So when the business comes to you with a really small, simple thing, always say “that’s going to be hard’,” he advises.
The art of asking for help
A lot of developers and database administrators don’t know how to present their problem in a way that can be solved. Kyte says he gets a lot of queries in which the developer simply asks for help without adequately describing what has happened. There are no error messages, no symptoms are described, nor any hint as to what platform the developer is even working on. He says the best way to get your problem solved is to whittle it down to the smallest possible test case that reproduces the issue and then try to explain it simply.
“Create the problem as if you were explaining it to your Mum, use small words, don’t use internal acronyms, nomenclature, or phrasing that is specific to your vocation,” he says.
Kyte’s particular bugbear is acronyms, because they make it hard to know what the other person is talking about. For example, HSM could mean Hierarchical Storage Manager or it could mean Hardware Security Module. One of his examples was taken from a website called WTF which he explained — somewhat disingenuously and to great hilarity — meant Worse Then Failure.
Too much code
According to Kyte less code equals fewer bugs. “We measure in our industry bugs by lines of source code. The industry average is one bug for every 10 lines. If you cut the amount of source code you write in half you have, almost by definition, cut the number of bugs,” he says.
Don’t hide your mistakes
He believes developers would rather hide their mistakes then deal with them, so they often ensure that errors are caught rather than examined. They write lines such as the notorious (in Oracle circle’s at least) ‘when others then null’. But this can lead to huge systems errors and its better to fess up because unknown errors not only can happen, they will happen, says Kyte.
“Developers have this fear of letting an error propagate back up to the client application. ‘If my code fails it will make me look bad’, so they try to catch every error and make it disappear,” he says.
After the presentation Computerworld asked Kyte about trends in database management. He identified two:
Databases will get larger and larger because nobody deletes anything, they just insert new stuff.
“When I joined in 1993 100 gigabytes was a gigantic Oracle database. In 1997 when we loaded an index for a terabyte database we would issue a press release. Nowadays a terabyte is a rather small to medium sized database. Many are 10 to hundreds of terabytes in size and only growing.”
Kyte says the other big trend is availability and the necessity to find ways of upgrading the database while it is in use.
“In 1993 when people went home at 5pm they actually went home, we didn’t have smartphones – if you weren’t at work you weren’t able to access the database. Nowadays the database is always on, always running.”
If you think it’s tough writing a review in 140 characters – try coding it
The business comes to you and says that it wants to tweet user reviews so they are suitable for texting, which means they can only be a maximum of 140 characters. On the face of it a simple fix, but in reality extremely complex, as Kyte pointed out in his presentation. The original problem can be found at www.contrast.ie/blog/there-are-no-small-changes but Kyte has added additional issues.
To gain an insight in the extent of the complexity, here are the first 10 questions that will need to be addressed:
1. How do you truncate the data?
2. Do you display an error message when it exceeds 140 characters?
3. What’s the explanation given to the user for truncating the message?
4. Who will write that error message (ensuring that it is grammatically correct and that the explanation makes sense)?
5. What will you do with existing or legacy data - do you just chop off existing reviews at 140 characters?
6. If you leave the legacy data as it is how do you explain to users with new entries that while a previous review was the size of [the novel] War and Peace, they’re only allowed 140 characters?
7. What browser will support it – Explorer, Firefox, Chrome, Safari, Android, iPhone – and who’s going to validate and test that it works in each browser?
8. Should you have a character count so users know when they are reaching 140 characters?
9. SMS has a special character set in which some characters – such as the Euro symbol – count as two characters, so if the user types that in they’re message will only be 139 characters, how will you communicate this to the user?
10. The Oracle database doesn’t come with the SMS character set, can you build a character set translation?