Over the last few years, I've worked a lot with various customers on finding better ways to build database software, often using the principles of DevOps to drive the change. A lot of managers and leads want to see a smoother process to help their teams become more efficient. DBAs often want less overhead and friction in the process, while developers just want to deliver code.

In many cases, however, what lots of management wants is speed, and they're looking for ways to increase their current speed and deliver more software. Their current rate of development might be quick enough if you can reduce your bottlenecks. Making communication easier, limiting the slowdowns from handoffs, and reducing the risk of mistakes are everyone's goals.

However.

What I see too often is that both their current process and the new one are often lacking fundamental database design and modeling. Developers aren't well-trained and make design decisions based on an (often) incomplete spec. They alter schemas to fit the immediate challenge, without thinking about the future. Good database modeling considers the often unasked questions and unspoken rules of the problem space.

Moving to a smoother process that allows code to be merged, tested, and released in a quicker fashion is great if you are writing good code. It's less great if you aren't. Most of us have a lot of poorly architected schemas and don't need more challenges from more bad designs or bad code.

I wonder how much time most of you spend on database modeling? Do you try to out more than one design? In this podcast, John Ousterhout talks about designing a system twice. He tries to get his students to come up with a second idea for a problem, which often brings out a better design. I wonder if this might not be a good idea for database modeling as well.

I'm sure most people do their best to build a good data model, but experience often teaches us that the way we decide on a table structure, data types, keys, indexes, and more changes as we learn more. Our experience can help us make choices that perform well over time and don't limit flexibility.

Is design an important part of your development process? Do you have guidelines for your organization? Do you consult more experienced database people? Or to inexperienced people ask you to review their choices? Building a more efficient software development process should help you to move code to production more smoothly, and therefore quicker, but it shouldn't be used to deploy more poorly written solutions. Take the time needed to implement well-designed and tested code, including your database code.