Design a la Steve Jobs

Today I saw an article interviewing John Sculley, former CEO of Apple.  He spoke about the early days of Apple, Steve Jobs, and a lot about, Design.  I loved many of the things he said.   Here are some excerpts:

Steve, from the moment I met him, always loved beautiful products, especially hardware. He came to my house, and he was fascinated, because I had special hinges and locks designed for doors. I had studied as an industrial designer, and the thing that connected Steve and me was industrial design. It wasn’t computing.

Steve had this perspective that always started with the user’s experience; and that industrial design was an incredibly important part of that user impression. He recruited me to Apple because he believed the computer was eventually going to become a consumer product. That was an outrageous idea back in the early 1980s. He felt the computer was going to change the world, and it was going to become what he called “the bicycle for the mind.”

Consuming Huge Amounts Of Unstructured Data

The recent presentation about Oracle Data Storage started me thinking about data.  I’ve worked with the Oracle database since 1995.  Lots of structured data in fields, tables and databases.  A certain amount of my job has been to turn these large amounts of data into usable information.  The result of which itself may in fact be unstructured, such as “the trend is …”.

But when I think of it, so much of what I actually consume and interact with, is in fact, very unstructured.  I started making a list of everything.

So much Content on the Web!

Google
Blogs and feedback
Webpages, articles, including animated GIF files that help explain things
News
Linked IN

Poor Or No Error Trapping

More Architecture Mistakes To Avoid

One thing that should be blatantly obvious to anyone who has ever had to fix some code on the weekend, or in the middle of the night, is the importance of excellent error trapping and logging routines.

When you need to fix something, now, you don’t want to be reverse engineering the code or the whole system.  You want to know what happened, and what to do.  Now.

You need what I call, instantly digestible error messages.  I don’t want to hunt it. I don’t want to kill it.  I don’t want to clean it.  I don’t want to cook it.  I just want to eat it.  I want both the cause, and the solution, in the same message.

The error trapping routine must be totally reliable.   Let me list some strange things that I’ve seen in production.

Complex and Useless:

System Performance: Cobol Versus Database

More Architecture Mistakes To Avoid, Database Design Mistakes To Avoid, Tuning

When I started working with Oracle, I helped to replace a Cobol system. For a while, the company systems ran half on Cobol, and half on Oracle.  The Oracle 7 system was pretty slow then.  After the cold backups had run overnight, it was not unusual in the morning to see a query against a 700K row table take about 30 seconds.

I was asked to write a C program that only interfaced with the Cobol flat files, and read Cobol transaction records.  Each transaction was stored in multiple rows, and given repeating groups of records, could vary in size from a few rows, to dozens of rows.  The files contained about 700K to 800K rows altogether.  The program grabbed information out of the multiple lines, tallied the numbers up, and output one line of summary. Lots of IF statements, and loops.  About 800 lines of code.

I expected this program to take at least 30 seconds, given that database queries to similar size tables took that long, and that there was so much logic and so many lines of code.

In fact, the program ran in about 5 seconds!  I was really surprised.

But when you think of it, it should be obvious that