I am, almost without qualification, terribly thrilled to have moved our entire business onto new software.
It seems as though every day I find new reasons to be happy about the switch. The new software is so much better at almost everything. For internal purposes, it's self-documenting, and the interface is intuitive to learn, and it all Just Makes Sense — so my staff can do everything they need to do more comfortably and efficiently. Externally, the public-facing pieces at dryeyeshop.com look so much better, and most things work better in so many ways. Most of all, there's just so much scope to do all the things that I've always wanted, because the system is so extensible and customizable.
But there's a reason I said "almost without qualification".
There's one little thing about our previous software platform (in use here from 2005-2017) that I secretly feel a bit regretful about: It just had such an incredibly elegant database design.
You see, my alter ego is a database connoisseur. And by connoisseur, of course I mean nerd.
I can get really, REALLY excited about a database schema design that's extremely well thought out.
How did I become That Person?
I did not grow up with databases, for sure. The earliest I can trace my interest back to was when I was living in Thessaloniki, Greece, in my now distant youth. I worked for a start-up translation and interpretation company for awhile. On slow days, like after the history project somewhere in the course of which, for the first and — come to think of it — only time in my life, I took dictation, in Greek no less, from my boss's uncle, the deputy minister of the interior (no pressure!), but before the project translating brewery equipment manuals from German — or, to be more accurate, really bad Italian and English translations thereof (no, don't ask!) — into Greek for the new Amstel-Heineken facility nearby. Well, as I was saying, on those slow days, we built our own terminology databases where we would collect terms relevant to local industries who might eventually need our services, and locate equivalents in every western and eastern European language we could manage. I remember page-turning a brilliant oenology book, for example, written by a local, alongside an equally brilliant English translation, with a yellow highlighter. So the database wasn't very sophisticated. So what? It was a database. It was Fun.
Not long after, I found myself transplanted to the Seattle area and working as a marketing assistant to an ex-Boeing sales executive who marketed used commercial jets for sale or lease, for a finance company. About twenty-five minutes into the job I discovered that, unbeknownst to my boss, he was desperately in need of a database to track the aircraft, the airlines, and many things in between. I mean, there was no way I was going to do all that work by hand, if it could be automated by putting everything in a database. Besides, mail merges were annoying.
At that point I was off and running. In casual database conversation with my dad (MIT-trained computer scientist and mechanical engineer), I found myself flinching under a shower of scorn for the software I was using which, according to him, was not a "real" database, not truly "relational". Fine. I invited him to the office and let him lecture me at a whiteboard. (Whiteboards are another obsession of mine, but that's another post for another day.) All about... relational databases, and what they mean and how they work. I won't pretend I "got" quite all of it right then and there, but after attending a software conference with him in Halifax, Nova Scotia (talk about a den of nerds... bearing in mind this was in the forgotten days before the dot.com revolution when nerdiness went mainstream), and continuing to grow my own databases, I was well on the way.
Not long after, I moved to San Francisco to work at the company's headquarters. It seems the aircraft leasing business division I was in had a painful history of failed database projects, notwithstanding the intensely brainy merits of the computer programmers employed by the parent company. The problem amounted to no one actually understanding what this particular business division did except its executives, who were much too busy doing deals to stop and explain things to anyone, let alone programmers, and let alone in terms mere mortals might understand.
So I set myself to understand it. I rifled through dozens upon dozens of file cabinets, the filing systems (lack thereof, rather) which indicated that the administrative staff who did the filing had no more idea than the programmers of what it all meant. I had conversations. And more conversations. I picked brains. I read reams of legal documents — leases, sale and purchase agreements, novations. I reviewed every single deal done since the division started. I pondered the life and times of aircraft which somehow had five or six "special-purpose companies" (entities registered, in our case, in the Cayman Islands for tax purposes) as sequential registered owners in a surprisingly short space of time. I studied engine life-limited parts and calendar-limited parts and how maintenance reserves were calculated and I could not tell you what all else. And I started to grasp how everything hung together.
Then I started working with a software development firm in New Jersey. To this day I have no idea why they were chosen (it was a commitment made before I arrived) but they were really good. I concluded quite quickly, though, that we could never hope to have a better outcome than previous attempts unless I learned a lot more about database design.
This could perhaps be described as the beginning of an offshoot of my earlier translation career - this time, translating business and tech people and concepts to each other. Or maybe I mean a marriage broker of sorts.
Somewhere in there, I fell ever deeper in love with database design. I obsessed about getting our database — which was constantly growing in size and complexity — right. I would wake in the middle of the night with a new idea and start re-arranging the schema again. I would fly out to New Jersey every couple of months and rip up old things and create new things. I think back on those days and how those poor programmers must have loathed me.
Fast-forward to 2005, when I started The Dry Eye Company in Florida, after ten years in various roles in aircraft leasing in San Francisco and London. I had absolutely no clue what I was doing or how e-commerce worked. But I Knew Databases. Naturally, I found and ran with the e-commerce system that appeared to me to have the best designed database structure around. It was so smart! The level of granularity of the database was just so pleasing, and allowed so much control at so many levels! Never mind that the user interface was increasingly clunky and 1990s-feeling as the years went on. Never mind that the front end looked even clunkier. Never mind that my staff had to run in circles to figure out how to do things and had to constantly document everything they did because there was no audit trail. It was just such a good database!
I finally buckled to the reality of our growing practical needs, and ditched it in favor of something that actually does all the things we need.
But I can't help every now and then, when I run up against a database-related shortcoming of our new software, glancing back at the beautiful, elegant, efficient database structure of our old platform. Be still, my beating heart!
← Older Post Newer Post →