Interview with Rob Garrison
March 22, 2007
Database Journal interviews our own Rob Garrison. Rob is a database designer and developer at Corillian. With ten years of database development experience, he has helped to develop software that is used by more than a third of the online banking customers in the US. In this interview, Rob shares some of his experience plus he gives us an inside view of a new interactive OLTP database series he is writing for Database Journal.
DBJ: Tell us a little about yourself and your career.
RG: I started working professionally with computers in 1985 in the Air Force. I've been programming since 1992 and specializing in database development since 1996.
DBJ: What are your major responsibilities and accomplishments?
RG: At Corillian, I have been involved in multiple teams and multiple projects, always as the database designer and developer.
Our software is used by more than a third of the on-line banking users in the United States. The exact same schema and code is used by small credit unions as well as banks with over 20 million on-line users. These large customers continue to push us for huge scalability while all our customers push us for reliability, quality, and ease-of-use. It is great work and great fun.
My most important accomplishment was developing the complete database design and all database coding and unit testing for Corillians current authorization and authentication system. I had developed an automated database unit test framework on a previous project and used it extensively on this project. After the project was complete, I was given permission to publish the framework. I cleaned it up a bit and published the framework as TSqlTest.
Writing: I have been writing internal documents in my job for many years. In 2004, I decided to go public by writing for sqljunkies. Now, Im writing the SqlCredit series for Database Journal and loving it. Writing is a great way to keep my skills current and give a bit back to the community, which has been so good to me.
DBJ: Which database do you use most in your daily work?
RG: On my current project, we use SQL Server 2005 exclusively.
DBJ: Which operating system do you use?
RG: Corillian has always been a Microsoft-centric company. We use Windows XP on our development systems and various versions of Windows Server in production.
DBJ: Which language...
RG: I have been neck-deep in T-SQL since my first day at Corillian. That is where I spend most of my time.
On my current project, we are using Powershell (including Powershell remoting) to great effect. We use it to automate the deployment of our software stack to an nbox system with no humans involved. If you havent started using Powershell, check it out. It is very powerful stuff.
DBJ: On January 29, 2006 you began a new series of articles on Database Journal. Give me an overview of the project.
RG: The idea of the SqlCredit series is to see the process of development of an OLTP database. So at the beginning, the requirements are basic and fairly sketchy. The design and requirements will evolve over the life of the series.
The series will also illustrate principles of agile development. The readers will be asked to play the role of product owner, developer, and QA.
The code will continue to grow throughout the project as new features are added and old features are refactored. Just as in a real development project, we dont know everything up front. Things will evolve based on changing requirements, scalability needs, the version of SQL Server used and other factors.
Literally, I dont have the whole series mapped out. I expect to get the basics down, switch to using SQL Server 2005 features and then add more scalability. Outside of that very simple roadmap, well have to wait and see.
DBJ: Who is your intended audience with this project?
RG: The series is aimed at current database developers as well as general programmers and administrators wishing to learn more about database design and development.
DBJ: What do you hope to accomplish with the project?
RG: I hope to help readers understand the principles of good OLTP development, but I also hope to learn from readers as we dialog about the project. Thats why the forum is critical to this project.
Writing also pushes me to challenge my own assumptions about design and coding. What is the best way to design a credit card database? Well, it depends. Database design is not simple. It is made up of equal parts art and science, but thats what keeps it interesting.
DBJ: What are some of the common mistakes developers can make when designing an OLTP database?
RG: The fundamentals are well known to database professionals, but I see people missing the fundamentals regularly. These include things like unique indexes (primary key or not), clustering, good indexing.
Frankly, the most common mistake I see is managers assigning database design to people who are not database specialists.
DBJ: I see you're trying to get the DBJ community involved, why is that? Why not just write the articles without them?
RG: When I read articles, I often have questions or disagree with certain assumptions. This series is interactive. If readers disagree with parts of the design or coding, or they want to change something about the requirements, they can post a message in the forum. I check the forum regularly.
The second installment in the series included open questions about alternatives for design and coding. You will see examples of the forum affecting the project starting in the third installment.
DBJ: What would you say to someone struggling with a development or maintenance project?
RG: I am completely sold on the value of automation (automated builds, continuous integration, automated testing).
For an existing project where youre having quality and/or schedule issues, the only way you will dig yourself out of that hole is to use automation for unit testing and QA testing.
For new development, start out right. Get the continuous integration environment up right away. Build unit test validation into the standard build process. Dont allow the build to stay broken.
And for database developers, dont cop out on automated testing. Dont claim that the stored procedures, functions, and triggers are tested by the calling codes tests. Thats ridiculous. Build your own automated unit tests, and dont ship your code until you are confident that it works.
DBJ: What would you like to be doing five years from now?
RG: I would love to be in a database-focused architect-level position where I can be deeply involved in both design and development. I also hope I will still be writing.
Thanks for answering our questions and sharing your knowledge and experience, Rob!