As the common wisdom goes, the best way to fix a badly designed system is to design it right in the first place.

I know all to well just how much truth there is in that. The challenge is in telling when a design is bad in the first place, which is more difficult than it sounds. There are all sorts of metrics that can be captured during the development process, but none of them will yield any true indication of how good (or bad) the design actually is. Experience tends to be the only thing that is reliable, and even then it can often just be a “gut feeling” that something is wrong and incredibly difficult to identify what exactly that is. When a design is mediocre, it’s even harder since there is often an equal mix of good and bad making it all that more difficult to tell one way or another.

I’ve seen a lot of interesting things, a small handful of amazing things, quite a few questionable things, and even some amazingly horrifying things done in the name of design. I’ve had to dig deep into systems and their design to either work with them or fix them (usually fix them). Through that experience I have discovered that the design of a project can be summarized with one of two simple characteristics: one for good, the other for bad.

I often hear statements in the form of “X is cheap, don’t worry about it”. This usually comes up in design sessions, software or infrastructure, it doesn’t matter, you can usually find or hear a statement in this form in either type of design session.

The most common versions would be in reference to disk space, bandwidth, and CPU.

I suppose this type of thinking is a result of the effects of Moore’s Law. One of the troubling things about this sort of thinking is that it is frequently wrong and is indicative of someone with a closed mind, an inability to see the big picture, lack of insight, short-sightedness, or any other similar phrases. In all cases, when someone makes an X is cheap statement it’s a safe bet that they haven’t really thought things through. These statements are very dangerous, particularly if you happen to be in a design session when someone says this and is of particular concern if that someone is a team leader or manager.

The most dangerous aspect of these statements is that on the surface they may appear to be accurate and correct. Unfortunately, unless we are designing as system that people will only look at (ie. the surface), rather than actually use, it is rarely correct.

A few weeks ago I decided that I needed to learn more about the BlackBerry from Research in Motion (RIM). So I made a call to a friend that works for one of the local cell providers and asked if he could hook me up with a demo device for a couple weeks. A few days later and I had a nice red BlackBerry curve and a SIM card to use.

To be fair, I was already certain that I wasn’t the BlackBerry personality. I’m a geek, as long as I can get to a computer, I can get to my email, I certainly didn’t need it clipped to my belt. I was wrong. I now understand the addiction of the “CrackBerry”, it will be hard to give the demo unit back, really hard. It was a Berry good experience, withdrawl is going to be rough.

Setting up email was a breeze, so was adding extra email accounts for Gmail. Facebook was already on the device, as was Yahoo messenger. There was no MSN or AIM clients, but that was quickly remedied with a download followed by a painless install. The web browser was okay, there is only so much that can be done with the screen resolution, and the browser had several viewing modes to help with this. I did try Opera Mini and it ran fine, and behaved like a desktop, but due to the screen size it too wasn’t perfect. Both were more than adequate though, and definitely better than the average cell phone. Google maps is so cool on a GPS-equipped mobile device that it was almost spooky and the navigation applications that I trialed were extremely good as well. The sensitivity of the GPS receiver is excellent, in some locations it outperformed my handheld GPSr unit. The keyboard is far more functional than I ever imagined, accessing punctuation and symbols are trivially easy and the “smart” behaviors really improve input speed rather than hinder it. It is so good that I am writing and composing this post on the BlackBerry!

I have a confession, I’ve fallen victim to the power of Steve Jobs’ Reality Distortion Field. I’ve been glued to the live “blogcasts” of his keynotes from MacWorld, Apple WWDC, and the special event announcements/presentations. I don’t even own a Mac! …but now I know I want one.

Now that I have that off my chest…

I was extremely pleased as I watched the keynote from the September 5th Apple Special Event. What pleased me the most was confirmation of some of my previous musings by the announcement of the new iPod Touch. This device confirms what I suspected, the “touch” is the first of Apple’s embedded hardware platforms. When the iPhone was announced, it was the fact that this platform was running OS X, enabling Apple to leverage a self-hosted environment in Mac OS X. This has been a competitive [and strategic] advantage that QNX enjoyed in the past. The iPod touch is using the same platform and derives the same benefits.

Apple has proven they have the ability to leverage this platform, I think we are going to see some interesting products emerge from this more rapidly than anyone expected. The iPod touch was announced only 3 months after the release of the iPhone, that is an insanely short period of time between products. It also means that in order to even get the device manufactured in time for the announce availability, that the hardware had to have already been in manufacturing when the iPhone was announced.

I’ve been thinking about Apple recently, just like everyone else many thoughts have been provoked by the upcoming iPhone release as well as the latest beta release of Safari. I don’t own a Mac, and I’m not a Windows fan either, my background is in embedded systems and software, I run QNX, Linux, and Windows on my network.

The most interesting things that I have noticed seem to have been missed by the mainstream, or at least I haven’t seen or heard a lot of commentary on the things I’ve noticed.

I’ve doing a lot of thinking on the topic of whether you can or can’t mix object and relational models, what I have discovered has been quite enlightening. In my previous posting, I determined that the same data hierarchies can be represented in either an object orrelational model. I also determined that you can mix the models (why not?), but that the trick is not in the mixing but in the realization that the model you have is a mixed one. The sad realization was that most people do mix the models and are completely unaware of having done so, and I needed to figure out why (and how) this was happening.

The use of IDs in objects is where the models typically mix, and also where most people fail to realize that a mix has taken place. Seems that the concept of a simple integer id incorporated into an id is a seductively powerful concept. I won’t claim to completely understand why this is, but I will share with you my thoughts on why the id has such seductive power that even the die-hard OO zealots fall victim to it’s allure.

I’ve been working on a system written in .Net/C# that uses SQL Server, my database experience prior to SQL Server included Oracle, Ingress, Sybase, Postgresql, and some MySql. Each had their quirks, but I’m learning more and more of the SQL Server quirks, and at times seriously having to wonder how Microsoft gets off calling this an enterprise class product. I will fully admit that some of my complaints are with how .Net communicates with SQL Server, and these probably are not Sql Server’s fault.

Here is my short list of gripes (in no particular order):

I have often heard people say that you can’t mix object models and relational models. I have to admit that it took a while for me to fully understand, and now that I do, I’m certain that most people that said it to me, didn’t. That sounds a little harsh and it probably is, but the people most likely to impart this morsel of wisdom probably have comp-sci degrees and learned how to program in an academic setting. They probably believe in “pure” programming methodologies as well, and talk about patterns, and anti-patterns, and extreme programming. Unfortunately, most are what I have previously described as fragile developers.

Anyhow, back to the topic at hand… mixing object and relational models.

There really isn’t that much difference between object and relational models. In fact, if you were to look at an entity-relationship diagram for a relational database and a object model diagram from a distance you probably wouldn’t be able to tell them apart. The truth is that I have yet to come across a data model that can’t be represented by either model.

About a month ago, Mark Zaugg handed me a copy of this book, he’d bought it but had not yet had the time to give it a read. It was a very interesting read, quite unlike any other book I have ever read on a technical subject. The author (Stéphane Faroult) has themed the book on the classic The Art of War by Sun-Tzu, and included many quotes and examples of a historical military nature. That might seem pretty odd for a technical book, so you’ll have to trust me when I say that it works.

While I was fumbling around attempting to recover the few posts from my original blog, Trever managed to find that the Way Back Machine aka Internet Archive not only managed to index my site, but it had a complete copy of the original postings. I have transcribed them into the new blog, which was nice enough to let me back date them so that the appear in their original order.

Three posts have been recovered, hopefully they are still of some interest and relevance to others.

To Trev:
for( i = 0 ; i < 100 ; i++ ) printf( "Thank you!\n" );