Thursday, February 22, 2007

Tools and dumbing down...

Just recently, I commented on an article "revenge of the calculators".  It talked of the dumbing down that all too easily happens when one relies far too much on their tools.  Sort of like the numerous reports of people following their builtin GPS navigation systems into rivers, dead ends, buildings, sand piles and the like.

Kathy Sierra just wrote about the same issue

I do believe tools are necessary - her analogy of tweaking postscript rather than using a word processor hit it dead on.  You sometimes do need a tool to be more efficient - the inner workings of postscript are not useful to most people (glaring exception would be the people that make the tool that generates postscript).  However, the cashier that cannot make change - or recognize when the machine is telling them to do something clearly wrong (because they plugged in the wrong numbers) is in a heap of trouble.

The hard part is finding the fine line between what you need to know and what you can remain dumb about.  I struggle with that line we all of the time with the database.  There is a lot that we don't need to know (it might be interesting to some of us - but we don't need to know some things).  It frustrates me sometimes when people insist on learning internals - prior to mastering analytics, SQL in general, transaction semantics, physical and logical design, and so on.

On an unrelated note - I was stumbling around this morning and hit this page.  For some reason I was reminded of being a kid and people would counsel you: "when someone does something bad to you, just breath for 10 seconds before responding - cool down first".  I wonder if their 30 second advice actually works.  If my experience with the typical end user is taken into consideration - there is 0% chance that it does!



The internet is just broken for me today.  Hate those "unknown errors":


At least I didn't have to count to 30 for this one.  I wonder of the advice to "please try again" is different if they encounter a "known" error :)



Blogger Phil said....

"Please wait 30 seconds", yeah not too likely to work. Application developers need to code how to handle this scenario to avoid cascading failures (this would be a similar phenomenon to bus bunching).

But even "experts" will get how to handle scenarios and issues wrong.

With a recent customer experiencing problems with their 12 DBWR processes being 'slow' (on a 4 GB SGA and 48-CPU system), one suggested solution was to increase the buffer cache. This was from a person who professed expertise in database tuning.

When I pressed him for his reasoning, he responded "Statspack is showing high buffer busy waits, so I need more buffers." I suppose I can give him some credit for not pointing at the buffer cache hit ratio...

What is woefully lacking at this customer is an understanding of how to do root cause analysis...they're spending time applying "bandages" on top of "bandages". It will be 'fun' to unravel their mess...

Why don't they spend time doing this? "We don't have time, there are too many problems we have to fix."

I wonder why...

What I'm saying is this: you need tools, but you also need some understanding of how the system works. You can't do analysis without context.

Thu Feb 22, 08:47:00 AM EST  

Blogger bill said....

waiting 30 seconds doesn't work either. all you get is the same message.;-)

Thu Feb 22, 08:51:00 AM EST  

Blogger Basil Faulty said....

Several months ago our web development lead proclaimed "the database is a black box". I wished him good luck and took a seat in the first row. Some people learn only form their mistakes. Or don't learn at all.
The only team whose apps are having performance problems - the web team.
We gave them a whole node from a cluster - it didn't help. Their apps are slow even at 3AM - when nothing else is using the database.
Well, the newest theory is "the database is not busy enough".

The good news: in this industry geeks always win at the end. Extra systematic knowledge of fundamentals always helps. And, because of the competitive nature of capitalism, "cargo cult" development and management always fail. But that's a different story.

Thu Feb 22, 09:10:00 AM EST  

Blogger Tim... said....

Tom said... "It frustrates me sometimes when people insist on learning internals - prior to mastering analytics, SQL in general, transaction semantics, physical and logical design, and so on."

I get this all the time. People ask me questions only a kernel developer could answer, when their previous posts make it clear they've hardly used Oracle.

My advice, step away and don't make eye (forum) contact. :)



Thu Feb 22, 09:59:00 AM EST  

Blogger jforonda said....

"Please wait 30 seconds.. do not hit refresh continually" reminds of of this: quality_story.cfm

Funny excerpt from that page:

Another argument can be made for the practice that became common during the US experiment with the Volstead Act (Prohibition). Grape producers in California would ship bricks of dehydrated Zinfandel grapes east, to Chicago and New York in railcars. These concentrated bricks of sugary grapes came with a strong warning label: CAUTION! Do not add these grapes to 5 gallons of water and five pounds of sugar with yeast, or it will ferment into wine, which is ILLEGAL. It was a strange time to be a winemaker.

Thu Feb 22, 10:21:00 AM EST  

Blogger Bill S. said....

You broke the internet, Tom? Al Gore is gonna be PISSED.


Bill S.

Thu Feb 22, 10:30:00 AM EST  

Anonymous Anonymous said....

...And of course, some people say SQL dumbs down database management systems.

Thu Feb 22, 02:23:00 PM EST  

Anonymous Patty C. said....

I also believe that some tools are helpful and time-saving, others are downright dangerous. I once had a junior DBA using a GUI OS tool who accidentally dragged and dropped a Unix filesystem for a database into a new location while the database was up. Not only did the database go down, it took us 1/2 hour to find the location of the filesystem!

Thu Feb 22, 02:30:00 PM EST  

Blogger Bill S. said....

Tools should be used exactly what they were meant for - as a helpful assist, NOT as a replacement for knowledge.
Nothing makes me gag faster than a cashier that can't figure out how to make change. That's basic math, stuff you were taught when you were 6 years old.

Bill S.

Thu Feb 22, 02:39:00 PM EST  

Blogger SeanMacGC said....

Anonymous said:

.And of course, some people say SQL dumbs down database management systems.

With respect, that is not what Chris Date's gripe is about primarily; it's more about how he views SQL (particularly pre-92) as a perversion of the Relational Model, which by extension will be manifest with DBMSs.

I know of few people who are so willing to expose their own thought processes to such searching examination for logical integrity as Chris Date is, and invariably those who are most critical of him are woolliest in their own.

Fri Feb 23, 04:53:00 AM EST  

Anonymous Anonymous said....

Surprisingly enough - those who regularly use unix shells seem to be in better shape than others - relying mostly on point-and-click tools.

Fri Feb 23, 08:17:00 AM EST  

Anonymous Barto said....

I worked in a company where, after the reboot of any productive server, the mail telling the server was again online asked the users (in the order of few thousands, in diferent geographics locations) 'please log in sequentially'. We always guessed if it was a kind of joke the support guys wasted to anyone.

About the internals, I, as a developer, find this information interesting because one usually could find interesting and usefull design ideas.

Fri Feb 23, 12:41:00 PM EST  

Blogger Alberto Dell'Era said....

But have you ever noticed that studying the internals is very often (I'd say "almost always" personally) is the *only* way to understand a feature ?

Once you have mastered the feature, you can forget about the internals, true; but then, if you try to explain the feature to others using a simplified way (an abstraction, a metaphor, a similitude, whatever) ... you are unable to explain the "real thing", and you risk to put the "pupils" on the wrong path.

Fri Feb 23, 05:05:00 PM EST  

Anonymous Anonymous said....

just got a ORA-01654 unable to extend INDEX ASTKOM.SYS_C006291 in tablespace FLOW_1!!!!!!

Fri Feb 23, 06:13:00 PM EST  

Blogger Jim said....

Ditto. I sent him an email.

Fri Feb 23, 06:15:00 PM EST  

Blogger Sanjay Singuri said....

Could these "The Broken Internet" and "The Server too busy" possible mean job opportunities for people who have a solution for just like this :-)

Sun Feb 25, 02:43:00 AM EST  

Anonymous TTJ said....

There is a dangerous assumption around that command line is good and point and click is bad.

In real life there is a lot of really dangerous operations which are best done in a properly designed GUI.

Sun Feb 25, 06:02:00 AM EST  

Blogger Emu said....

Talking about the internet being broken...its may as well be when I search for "expert oracle programming". It tell sme this book by Tom Kyte will be finished in June 2006 - if I can wait till then. hmmm Tom are you still writting this? Any update on when it might be finished? Does the book cover RLS?

Sun Feb 25, 08:44:00 PM EST  

Anonymous Allan said....

I just started reading a book, "How to Solve It: Modern Heuristics" by Michalewicz and Fogel. Though I've just scratched the surface it really seems to resonate with this theme. In the introduction, the authors illustrate that most of us don't learn HOW to solve problems, only how to apply specific strategies in staged scenarios.

For example, we learn in Junior High School how to solve quadratic equations. At the end of the lesson, we can solve all the homework problems because we KNOW that they involve quadratic equations in one way or another. But absent this context, far fewer people can recognize WHEN to try to model a problem as a quadratic equation, because basic problem solving skills are not taught.

Anyway, I have high hopes for this book based on the initial chapters.

Mon Feb 26, 05:49:00 PM EST  


<< Home