OK, you're either going to be fascinated by what I'm about to tell you, or you're going to think, "Wow, Christopher has one weird hobby."
Next weekend, you might be bowling, watching football or taking your lady dancing, I'll be dressed up in a tunic, like the ones you see in movies about Vikings, watching my friends in their armor hitting each other with swords made from rattan (you know, like old style lawn furniture)
I'll be standing there with other people, all dressed in clothing that was last popular in the 1500s or earlier. Some of them will have made their own clothing and accessories. Others will play medieval music or sing songs from the 1400s. There will be knights and ladies there, dukes and counts, and at this event, we'll sit in court while the king and queen give out awards to our friends.
We call it the Society for Creative Anachronism, and it’s what we do on weekends.
So why did I come to Akiban Technologies? First off, I had a good job at another company, but after 11 years it was time for a change. I took my time looking for a good company to work for. I wanted to go to a better job, not run away from the one I currently had.
I was sent a link to the Akiban site and I was immediately fascinated. The issue that I had struggled with for some many years, some one had a brilliant solution to it. My head was swimming with ideas about how they must be doing it. All the possibilities.
What my mind settled on was the core issue of dealing with large databases. The elegant solution, a highly normalized database, was always a dog in the performance arena. While highly responsive large databases usually had multiple copies of data, highly denormalized databases had triggers trying to keep it all in sync and a mess of a schema.
Chris Date, for example, writes: "I believe firmly that anything less than a fully normalized design is strongly contraindicated ... You should "denormalize" only as a last resort. That is, you should back off from a fully normalized design only if all other strategies for improving performance have somehow failed to meet requirements." Date, C.J. Database in Depth: Relational Theory for Practitioners. O'Reilly (2005), p. 152.
The concept of Table-Grouping seems like a no-brainer. Store data the same way you want to see and act upon it. The trick is making that not obnoxious to maintain. So what if you could have both? Speed of access with an elegant schema, without the need for tuning, fusing or compromises.
So with all that in my head, I applied to the company. It was one of the better experiences I had. Mixed in were the usual coding tests, design tests and personality quizzes. And did I forget to mention that after all these years, I was moving from enterprise application design and coding to testing. Testing! I don't know what I was thinking. But they explained this philosophy to me. “We're all coders here. All database people. We need a programmer to program tests to test the software, not write scripts”. I was intrigued.
For the longest time (maybe even forever) I've been disappointed in the quality of testers that had been assigned to test my work. Never has a “peer” challenged me in this manner. (Sorry ex-coworkers). So I decided it was time to put my money where my mouth was and take up the mantle. Besides, I really wanted to know if this concept was going to actually work. What better way to get confidence in a product then by pushing it to its limits and seeing how it does?
So now I'm here. And I'm not disappointed.