My ‘Accidental DBA’ story

I started out as a shareware developer in the late 90’s, initially working on a CSS editing product on VB4 among other tools for Web Developers (or Webmasters as they were then known!). Eventually I decided that I should join the corporate world, to learn about how big organisations operate and work with people smarter and more experienced than me. So I applied for and got a job with an IT consultancy.

During my time there I was mentored by a team of DBAs working with Oracle 8i. They were working on a sighting database as part of a government initiative for the protection of endangered wildlife. It was my first exposure to an “industrial-grade” DBMS, and the enthusiasm those guys had for their craft left an impression that would set the tone for the next decade of my career.

After a couple of years of consulting work, I changed to a more permanent team role within a retail finance company and moved away from Oracle to the Microsoft toolstack. Moving to SQL Server 2000 was something of a revelation: I remember thinking to myself, “Wow, databases can be friendly?”. I was particularly taken with DTS and how readily large amounts of data could be shuffled around from server-to-server. Enterprise Manager and its point-and-click query and table designers unleashed all sorts of possibilities for me. In time, however, I would learn that these GUI tools could also be dangerous if not applied with proper forethought and due care.

I have to admit that the whole RDBMS paradigm didn’t come that easily to me. Initially I saw it simply as a way to persist my application object data; something I later learned was quite common among AppDevs (Grant Frichey summed up this quandary well in his article on DBA/Developer communication). But in time I came to appreciate the subtleties of working with relational databases and got to grips with deployment techniques, like how to preserve the integrity of a schema during table object changes.

As our team started to face the pressures of shorter release cycles, and as tensions between Devs and DBAs became evermore frayed, my manager and I saw a need for a role that would keep the wheels of our application lifecycle turning. So for 3 years I did nothing but prepare and execute releases to our enterprise contact centre systems, working with both teams to find ways to make our deployments go a little smoother and a little faster each time. I discovered the wonders of Continuous Integration with TeamCity, integrating our build process with a Compare API, which helped us with our deployments as well as keep our environments in-sync. My manager helped me put a DevOps team together and over time we got deployments down to a fine art, making the best of our ever-narrowing release windows.

I enjoyed this work so much I recently quit my job to develop and market a tool for database professionals. So in a way my career has come full circle with a return to independent software development. The difference to when I started out 15 years ago is that the vernacular has now changed from “shareware developer” to “Micro-ISV”. Times may have changed and certainly the tools for software development and deployment have come a long way, but in a lot of ways database development tools are still stuck in the dark ages. Having worked on both sides of the Dev and DBA divide, I have been fortunate to gain an interesting perspective on the challenges faced with software delivery and operations.

So the gauntlet that I’ve now thrown down for myself is to make the best of that opportunity: to help teams work more harmoniously and simply get more releases out the door.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s