Wednesday, October 24, 2007

Busting Myths ...

I have spent an extended working weekend in Chicago. I have been appointed to another User Group board and am wrestling with many of the same topics I saw when on the ITUG board. The weather in Chicago was perhaps the best I have ever seen – three perfect fall days. The fall colors of the trees lining the river were pretty spectacular.

It reminded me very much of a fall trip I took recently in Colorado and the picture I have included here is of the Eastern approach to Independence Pass, the gateway to Aspen. The picture here is among my favorites, and from time to time I see it come up on my PC as my screen-saver pulls up pictures from a folder.

When I am in the major cities, I really do like to walk through galleries and admire the art. Whenever I am in London I stroll down Mayfair and when in Chicago, I head for Rush Street. The galleries I spend time in aren’t your usual high-profile tourist spots – and those familiar with London must be wondering what I am talking about.

But for me, the car dealers showrooms on Mayfair where once a McLaren F1 was a near-permanent exhibit, and where I can glimpse the latest Porsche’s, BMW’s, Aston Martins and other beauties, would never fail to get me to walk on down that street. In Chicago, there’s Gold Coast Bentley, recently upgraded to two levels and where the Lamborghini marque has been added to the regular stable of Bentley’s, Ferraris, Aston Martin’s and Salween’s, and once they even had a wonderful 8.0 Liter quad-turbocharged W16 1001 bhp Bugatti Veyron on display!

Chicago with beautiful fall vegetation, and great cars to admire and salivate over was at its very best.

The picture of the fall in Colorado does feature a 50th Annivsersary Corvette C5 Z06 – a great car. When compared to the cars of my colleagues, it barely gets a mention as talk turns to Mercedes Benz's, Porsche’s and Jaguars. And in Europe I get some pretty strange looks when I try to compare it with the better known super-cars. You see, there’s a terrible myth surrounding the car – it’s just an American muscle car that true performance fans wouldn’t really consider worthy of consideration alongside the current crop of high-performance exotics.

They are too heavy! They may be alright in a straight line, but they handle poorly! And they have no heritage, nothing that would find support among the well-heeled aristocracy! But is this really true – how do myths like this originate and how do they get propagated?.

When you look at a car like the Corvette, it has been manufactured for more than 50 years so it’s not all that new on the scene. Under the management of David Hill, Chevrolet worked very hard on both, the power delivery aspects as well as weight. It comes as a surprise to many that the car pictured weighed less than a Porsche 911 Turbo of the same year, and where horsepower and torque numbers were pretty identical.

But more importantly, in the difficult climate of one of the toughest endurance races on the calendar, the 24 hours of Le Mans, Corvette has taken its class 4 of the last 6 years – loosing once in2004 to a one-off special Ferrari; and then again, this year, to an extremely well-financed Aston Martin team. To put other cars behind it for all of these years, was a remarkable feat!

When I posted my blog “Bugs are Everywhere” and talked about the performance of SQL/MX, I received a comment that said “strapping an ‘Itanium’ rocket to an SQL/MX pig does NOT make it any sleeker”! And in a private email that wasn’t posted, one writer referred to SQL/MX with even less respect and called it “bloatware”! The sentiment was that it was just bad code.

But is it really? And what is good code? I had the opportunity recently to have an email exchange with Dave Finnie on this very topic. Dave is a gifted programmer at my previous company Insession and has contributed to a number of successful product developments – anyone running the ICE HPR-IP solutions is running a lot of Dave’s code. Dave believes good results can be obtained when code is readable, so that someone can fix it. When it’s understandable by any other coder, for the same reason. And when it works and performs as per spec – a bit of thought at the beginning of the project can make a huge difference! In other words, nothing really surprising here – pretty much what we would expect.

The perception of weight, or a heavy footprint, is always a concern. The decoupled nature of the GoldenGate TDM product has a source and a target component and we have always pursued a lightweight implementation for the source. In talking with my colleague Sami, to have any chance of keeping up in real time, you can’t add to the overhead of the source – the data has to get off the platform just as fast as you can shove it onto a link.

But nevertheless, in talking with Wendy Bartlett recently, she acknowledged that SQL/MX did have performance and stability problems in its first few releases. “We think that this has been mostly resolved in newer versions and that the problems at this point are more characteristic of what would be expected from making functional additions to the product.” Wendy added that another phenomenon that they saw was longstanding defects sometimes being exposed, for the first time, when the code meets a new application.

There is also the issue of how SQL/MX is accessed – is ODBC or JDBC involved? Are the applications, or indeed other infrastructure programs, accessing via these standard interfaces? There may be a potential for some performance related issues coming from these interfaces – and I for one, would really like to hear more from the community on this point.

But again, is the myth surrounding SQL/MX much the same as the myth around the Corvette? Has early examples of the product really tainted the expectations that much? I am not good enough these days to pull any code apart and check it all out – although I am sure others have.

When I bought the Corvette pictured above I emailed Chris Rooke and asked him what he thought. Chris is a very active and enthusiastic Porsche Turbo owner who actively races it on racetracks around the Western US. “There’s one that I race against and on some tracks I win, and on others he does. In terms of price performance, it’s a hard car to beat” was his response.

In the last days Hal Massey was on the Cupertino campus, and before he took up his new engineering position in Ft Collins, I just happened to notice a white Corvette in the parking lot. Yes, Hal is a very serious race-car driver and sure enough, he owns a Corvette.

Seeing both Chris and Hal, both of whom I seriously respected when it came to cars, providing such strong support for the car, made me feel a lot better. So then, why aren’t we all more aggressively pursuing the input of others who are now running SQL/MX in production? Why aren’t we spending more time engaged in sharing what we are doing – when I checked the ITUG SQL SIG Forum the last posting was dated mid 2006. Shouldn’t we be communicating more?

HP went to great lengths to get the “Mythbusters” from the Discovery Channel to blow-up one NonStop server complex to see how transparently and quickly the back-up data center took over – do we need to get them to bust the SQL/MX performance myth?

It was a lot of fun to watch the video and see the servers blown apart - but do we really need to see acts this dramatic to impress us? Are we waiting for something similar before we put an end to this myth?


David Finnie said...

Great blog, as usual, Richard.

Regarding what makes good code, and how you get there, I have the following pet rules of thumb. I wonder what others think and if they have others ?

KISS. It's a very over-used cliche (is that a tautology ?), but for a good reason. Keeping concepts as simple as possible can mean an order of magnitude difference in the time it takes for a developer to pick up someone else's code. Obviously some problems require some clever code to get you to a solution, but this sort of thing (clever coding) should be kept to a minimum. Although most of us can write "clever" code, it is almost never good coding. Most of the examples in Computer Science textbooks are fairly simple and elegant. Trying to ram elegance into every computing solution seems to often lead to code that no one else can decipher. It can even trip up the developer that wrote it after a few years !

Comments. All too often I see code with little or no comments. Worse still are when changes are made to fix a problem, and the reasons for the change are not clearly described in the code comments. Complex concepts need copious comments. Self-documenting code is always a great aim (and should be employed wherever possible), but some concepts are just too hard to explain using variable and function/method names alone.

Style conformance. A group of developers needs to fairly rigorously conform to a programming style for code layout, naming conventions, control block/object design, etc. It doesn't matter too much what style is adopted, so long as everyone sticks to the same thing. Readability and understanding are key here. It is amazing how difficult it is to read code properly when variable/function naming conventions are mixed, indentation style is inconsistent, etc. A lot of developers take offence at this sort of idea - they have their favourite style, and they're sticking to it. In the real world, though, someone else is going to have to read your code.

Choice of data structures. This lends itself to the performance goal. We should always be aiming for data structures that help our code scale well, and reduce the number of unnecessary operations (e.g. something as simple as remembering the length of character array so that we don't have to keep calculating it).

Honestly, things like language, IDEs, methodologies, etc. can make a small difference - it is much harder to be obtuse in Java, for example, than in C++ - but at the end of the day a developer can make things bad under any environment :-)

Anonymous said...

To tell you the truth, Richard, 90% of the problems with SQL, any SQL, are not the engines, but the drivers.

To put it in perspective, I watched a video of two friends in Atlanta running at Talledega (amateur sports car race). One drove a C5 Z06, the other a modified Infiniti G35 (mostly suspension/brakes, but catbacks and an aftermarket CAI, too). They played tag (have to wave people around since it is amateur) alternating who was leading. Consistently, the 'Vette would walk away on the straights, but couldn't handle the braking or corners even close to as fast as the G35.

So, each had advantages at different sections of the track, but overall they were very closely matched, as were the drivers. However, put a professional driver in either car, and it would have been all over.

The same is true for SQL, but goes even deeper. Ninety-five percent of good performance in SQL is database design. Get that right, and the rest falls in place. That's the build. If the body isn't aerodynamic, no amount of horsepower is going to make it fast. The last 5% is in addressing the problem correctly and taking advantage of what any given SQL can do. That's the driver picking the strength and weaknesses of his car on the track.

In both cases, most businesses fail. Databases are very poorly designed, deadline pressures result in "jury rigging", and the resulting database doesn't have a chance from the get-go. Even when a database is well designed, poor application design to take advantage of the database and poor SQL query coding can make the fastest database a dog.

I put to your readership to really examine what they have and what they are doing with it. Since it is SQL/MX, it should be easily portable to other platforms. Do they get similarly poor results, or is there a signficant performance difference. More times than not, I think they will find their application suffers no matter what platform they use and it is time for introspection rather than condemnation.


Palmer King

"Time Traveler for a better yesterday."

Anonymous said...

Your most recent blog entry talks about SQL/MX.

It's hard to say that that failed, but I think you may have highlighted some ways in which it hasn't succeeded as spectacularly as it could have. The quality and performance issues in the early days did tar it with that brush. Of course, SQL/MX was a great stride over MP in standards-based support, but it still was viewed as highly proprietary.

Adoption of database technology tends to be very conservative; the big names carry a LOT of weight.


Al Hoss