What Are We Still Doing Wrong

What are we still doing wrong?

Thomas Kytehttp://asktom.oracle.com/

Who am I

• Been with Oracle since 1993 • User of Oracle since 1987• The “Tom” behind AskTom in

Oracle Magazinewww.oracle.com/oramag

• Expert Oracle Database Architecture

• Effective Oracle by Design• Expert One on One Oracle• Beginning Oracle

“We do many things correctly. However, we data processing professionals (please don’t be insulted by that) still do many things incorrectly. Let’s look at a couple of examples.”

What I’ll be Saying today

Underestimating Complexity

Nothing is as simple as it seems - http://i.thefairest.info/funniest_thumbs/TrUf6c.jpeg

Eischer

http://www.contrast.ie/blog/there-are-no-small-changes/

Small Change

• We want to limit the length of a review in our application to 140 characters (SMS like)

• Easy, Trivial change.• Business demands it.• It’ll take what – 30 seconds?– Just find a code snippet on that there interweb thingy and

plop it in– Don’t need to design this, this is way too small of a change to

even think about – it’ll literally take 30 seconds to implement


Small Change – but think about it…

• What happens when exceed 140 characters– What happens to existing data?– What happens to existing interface?• Do you silently truncate?• Do you display an error message?– Is error message modeless?• Is error message even in another window, or just on

status?– Is error message modal?– What is the explanation given to the user? (one that they’ll

comprehend and believe to be true)– Who will write that message?– Do we know what the error message style is?



• We don’t want to round trip to server– Bad end user experience– Not scalable

• Hence client side validation– But database still must enforce this• Why? (Tools -> Options -> Content -> Enable Javascript)• Again, existing data??

– Who is going to code this javascript?• What browsers do we support (or not)



• What about usability?– I guess we need a character counter, it would be rude otherwise• Counter should probably look different near zero characters than

it does near 140 characters• If you just “find one on the interweb” – who – Does the testing to ensure it works everywhere– Verifies isn’t infected in some way, it happens

– Do you just stop accepting characters at 140?• If not, what do you do to make it obvious that something will get

chopped• What about cut and paste?

– How do we display existing data??


• How do you explain to the end users why their input is limited to 140 characters but the other reviews are the size of War and Peace?– Existing data!

• What about the implied restriction that wasn’t specified– We want to limit the length of a review in our application to

140 characters (SMS like)– What is the implied restriction??



SMS disallows many characters, now what???

“This is why as a UX designer you need a good understanding of what it takes to implement a feature before you nod your head and write another bullet point.”

Quote from article

It was very good, but

They missed a lot because – they are the UX designer…

http://www.joelonsoftware.com/articles/NothingIsSimple.html

Think about it…

• There is more than one way to do something– Can you put the Windows standard file open dialog into a

wizard? (yes, but it is hard)– Can you rethink your approach instead?• Yes, remove the wizard!

http://www.joelonsoftware.com/articles/NothingIsSimple.html

“Do not ask (yourself or others) how to physically implement something in a specific way (first specification). Rather – ask ‘how do I achieve this goal’.

Perhaps my largest frustration on asktom are the questions that demand a specific solution – rather than the best, easiest, most performant, scalable, whatever solution”

I say

Not knowing how to ask for help

http://blogs.msdn.com/oldnewthing/archive/2009/08/04/9856634.aspx

Think about it…

• Think it all of the way through• Be very specific– Supply everything you think it relevant– But if something isn’t relevant, hold it back

• Whittle your example down to the smallest possible case• Phrase the problem as if you were explaining it to your mom– Because we on the outside have as much inside information as she

does

• Think long and hard about the ‘edges’• Think long and hard about the implied constraints (we want to

limit to 140 characters for SMS, therefore…)

We write/generate Way too much code

Think about it…

• More code = More bugs, this epitomizes ‘more code’• So does this• We love writing cool code• You can reduce a million lines of code to a single

statement, if you know how…

http://A-Confusing-SELECTion.aspx.htm/

http://thread.jspa.htm/

“To be a good SQL developer, you should be able to imagine the query in terms of sets and in terms of algorithms at the same time.

It’s not enough to come up with a set operation that yields correct results. It will be inefficient.

It’s not enough to come up with a good algorithm that transforms your set as you need and try to force-feed it to the server using procedural approach. The servers are not good at that.

What you need to do is to formulate your query so that the optimizer chooses exactly the algorithm you need. And to do this, you should know both the algorithm and the set operations. You need to doublethink.

This is not always an easy task to do. But it definitely deserves learning.

And only if you learn it you will be able to harness all the power of SQL.”

Quassnoi

We pretend Everything will be alright

That is… We are in denial

http://demonoid.com/ - still down, was 2nd largest – Alexa top 500

Think about it…

• Errors happen – deal with it– Error codes were unclear, confusing and too technical– said the system repeatedly failed to accurately track student

attendance. "You would have a kid that had 20 unexcused tardies, and that would show up as zero,“

– "Many people were getting the wrong work-habits grades.”– mistakes on report cards– duplicated student records

http://www.washingtonpost.com/wp-dyn/content/article/2009/09/04/AR2009090402302.html?wprss=rss_metro/md

Think about it…

• Unknown errors not only can happen – they will happen• And we should not catch them– If you do, you should log them, and throw/raise/ “your

languages terminology goes here” them again

• When others then null – the “logic” escapes me, entirely.

http://www.hans-eric.com/2009/09/03/tools-of-the-effective-developer-error-handling-infrastructure/

Think about it…

• Quote “there are several problems with the error handling code above, some more severe than others”– Inconsistency, every developer will “do it themselves”– Information loss• About the error itself• To the data in the application (probably)• And the caller doesn’t know and probably destroys more

data– Automation un-friendly

• Quote “Implement a strategy for handling errors at the earliest possible time”• (just like archiving should be done…)

http://www.hans-eric.com/2009/09/03/tools-of-the-effective-developer-error-handling-infrastructure/

http://gen5.info/q/2008/07/31/stop-catching-exceptions/

Think about it…

• Quote “Where should you catch exceptions?”– At high levels of your code, you should wrap units of work in a try-

catch block. A unit of work is something that makes sense to either give up on or retry.

• What should you do when you’ve caught one?– What do tell the end user?– What do you tell the developer?– What do you tell the sysadmin?– Will the error clear if up if we try to repeat this unit of work again?– How long would we need to wait?– Could we do something else instead?– Did the error happen because the state of the application is

corrupted?– Did the error cause the state of the application to get corrupted?

http://gen5.info/q/2008/07/31/stop-catching-exceptions/

http://dobbscodetalk.com/index.php?option=com_content&task=view&id=698&Itemid=

Think about it…

• Quote “The arguments in favor of removing them were along the lines of”– The production code will run faster.– Professionally written production code is bug free, so there is

no need for asserts.– An assert firing causes the program to abort, which may not

be permissible, may cause data loss, and looks unprofessional to the customer.

– The data being checked may not matter anyway, so why check it?

• Let’s talk about that

http://dobbscodetalk.com/index.php?option=com_content&task=view&id=698&Itemid=

Security Matters

Security

• Oracle is very secure• Therefore, we don’t need to be, it just happens• Besides, it is not as important as having pretty

screens after all.• And if we add it later, – I’m sure it’ll be non-intrusive– And very performant– And easy to do

http://news.bbc.co.uk/2/hi/business/8206305.stm

Think about it…

• Quote: “Mr Gonzalez used a technique known as an "SQL injection attack" to access the databases and steal information, the US Department of Justice (DoJ) said.”

• Quote: Edward Wilding, a fraud investigator, told the BBC that this method was "a pretty standard way" for fraudsters to try to access personal data. He added that this case probably "involved extremely well researched, especially configured codes, not standard attack codes downloaded from the internet".

• It is clear from the article that the fraud investigator does not know what SQL Injection is

• Unfortunately – the same is true for many developers• SQL Injection is insidious

http://news.bbc.co.uk/2/hi/business/8206305.stm

http://www.takefreetime.com/2009/09/mass-infection-turns-more-than-57000.html

Think about it…

• Quote: “SQL injection attacks exploit weaknesses in web applications that fail to adequately scrutinize text that users enter into search boxes and other web fields. The attacks have the effect of passing powerful commands to the website’s back-end database.”• At least they get the concept correct!• Remember my example with “let’s grab some

javascript from the interweb and just include it”?– Just a little bit dangerous– More dangerous than this particular SQL Injection attack!

http://www.takefreetime.com/2009/09/mass-infection-turns-more-than-57000.html

Security MattersApparently, it won’t get better in the future

http://ha.ckers.org/blog/20090918/what-star-trek-predicts-about-the-future-of-information-security/

Think about it…

• The following are some quotes from the ‘article’• They are not only funny– They are true

• Do go read the entire article – insightful

• An example with Star Trek I’ve used in the past (having nothing to do with security) is about distributed databases…


Think about it…

• Physical security will always be a problem– How many times have we seen people open up random

access panels on the Enterprise and start pulling out chips when something goes awry or just start swapping them out right and left? Crawling through tubes to get past obstacles and the like… all point to the fact that even the most sophisticated military war machine of the future won’t stop some teen aged acting ensign in engineering from taking over control of the whole ship in about 35 seconds.


Think about it…

• PCI doesn’t stop hackers, now or ever– They don’t use money in the future. Probably because

consumers are so sick of having their credit cards stolen is my guess. I’m also guessing based on how many holes still exist; SQL injection still exists even hundreds of years in the future. So currency, and therefore the payment industry had to go. Even Quark trades in gold-pressed latinum - you don’t see the Ferengi taking plastic.


Think about it…

• Organizations will always ignore single points of failure, even after it bites them– I can’t even tell you how many times the Enterprise has

managed to damage the one and only di-lithium crystal that they have on the whole ship. They know they can’t whip up a new one with the replicators but they still don’t carry even one spare. Then they end up being stranded or having to use the sensor array to catch radiation from some exploding sun or some other retarded plan that always manages to work out exactly perfectly, but always necessitates near death experiences in the process. Why, for all that’s holy, wouldn’t you just bite the bullet and pay to have two on board?


Think about it…

• Virtualization security is an oxymoron - even in the distant future– I mean, really, how many times has the whole damned ship

been taken over by some overzealous holodeck character? Whoever wrote the holodeck hypervisor really needs to be put in a room with Warf for a few hours so he can explain with his batleth what the need for true physical and logical isolation is. Why some Sherlock Holmes character should have access to main memory, I’ll never know. Too bad we aren’t smart enough in the distant future to think about hardware isolation instead of relying exclusively on dangerously faulty software.


Think about it…

• The iterative development model will be proven bad for security and quality exactly 1,000,000 times but will still be used in production anyway– How many times have we seen engineering making changes

to the warp core while they are 200 light years from any star base or any other craft for that matter? And how many times has that gone smoothly again? No, it’s a bad idea now, and it will always be a bad idea. But then again, maybe you shouldn’t worry so much about keeping your data and integrity intact… it always manages to get fixed in an hour or so anyway, right?


A word on Best Practices

<Insert Picture Here>

Best Practices defined –

Consensus of expert opinions, based on actual customer experiences in practice.

Lessons learned.

Proven practices associated with a particular usage profile.

Baseline configuration rules - prerequisite to tuning.

Sounds all good…


Best Practices – It is easy with Best Practices to forget that once a practice has been branded as "Best", that it may represent certain tradeoffs and may involve noteworthy downside potential. It is also easy to forget the context for which any given practice was promoted as "Best", and therefore apply it in some inappropriate context.

- Bob Sneed, Sun Microsystems

Bryn Llewellyn on Best Practices

• Has chosen the right parents.

Prescribing best practice principles for programming

any 3GL is phenomenally difficult. One of the hardest

challenges is the safety of the assumption that the

reader starts out with these qualities

• Has natural common sense coupled with well-developed verbal reasoning skills.• Has an ability to visualize mechanical systems.• Requires excellence from self and others.• Has first class negotiating skills. (Good code takes

longer to write and test than bad code; managers want code delivered in aggressive timeframes.)

• Has received a first class education.• Can write excellent technical prose. (How else can you write the requirements for your code, write the test specifications, and discuss problems that arise along the way?)

• Has easy access to one or several excellent mentors...• Knows Oracle Database inside out.• Knows PL/SQL inside out.

Bryn Llewellyn on Best Practices

15:45-16:45 Sunday

S311456 – Online Application Upgrade

Hilton Hotel Imperial Ballroom B

Highly Recommended:

This (edition-based redefinition) is the killer feature of Oracle Database 11g Release 2

- Tom Kyte

In Conclusion


Always Question Everything – in a non-annoying way of course!

Take your time, really

(never time to do it right, always time to do it over?)

Question Authority…

What are we still doing wrong?

Thomas Kytehttp://asktom.oracle.com/

Technology

What Are We Still Doing Wrong