How the Agile Manifesto can apply to the database
In 2001, a bunch of people got together and wrote a manifesto on Agile software. There were two main factors that made the output suspect. First, the fact that they even called it a manifesto. Second, the manifesto had nothing to do with software. It talked about values.
For those in need of a refresher, here’s the “Manifesto for Agile Software Development:”
Somewhere along the line, we started doing daily standups, two-week sprints, maybe a little pair programming here and there. Since then our software output and productivity have sky-rocketed. Remember when we used to have an end-of-project company bug hunt How about the integration exercise that … never ended
Both of those things (and so many more hurdles) are obsolete. The one lingering question in my mind is: Why do database administrators always look like they’re playing catch-up Their plight reminds me of the “I Love Lucy” episode during which she and Ethel are wrapping candy at the chocolate factory.
Just like Lucy, DBAs believe they have everything under control. Everything is manageable and the “We can handle this!” attitude prevails. Then, the conveyor belt speeds up and starts to crush them. To bring this metaphor full-circle, on the other side of that wall from Lucy and Ethel, Agile software development feeds the conveyor belt with more and more applications.
Agile has inarguably done wonders for software development teams. They are more productive, they put out higher quality software, their work/life balance is improved. What database administrator wouldn’t want all those same things After all, the database is just as important as any other part of the stack. (Op-Ed Note: In full transparency, we actually believe the database is even more important.) And, just like the application uses code, we can find an analogue with SQL for the database.
Let’s walk through the Agile Manifesto and see how it can apply to the database.
Too often I hear from DBAs, “We don’t do it like that here.” There is an entrenchment of process and tools at the database level that frankly needs to be rethought.
When it was standard practice to release one application once a quarter, it made perfect to sense to have a DBA manually review the SQL script to make changes in production. Given the importance of the database, that was more than reasonable.
Now, thanks to Agile, there are hundreds of applications that release every two weeks. That means the same DBA is performing 150+ releases a quarter. There is no way that individual can catch every standards violation that puts data at risk. It’s time to stop pretending that they can and fix this pitfall.
Let’s be honest and engage in some simple problem-solving. Since the reliance on time-worn database deployment processes and tools is not working, it’s time to engage with the teams requesting and initiating the change. DBAs must take the initiative to adapt their interactions with developers to improve processes and tools. They might even need to choose new processes and tools (gasp!) to support how they build software.
Before Agile was all the rage, there was a time when RTFM was the catch-all response to “How do I…” That is not acceptable today. After all, Facebook doesn’t provide a manual for its product so that’s the reality we must live with, like it or not.
The working software we produce should guide users to the happy path. When users veer off that path, there must be an elegant and yet simple method to returning them to productivity. The same must be done for the database.
Unfortunately, this is easier said than done. At some point, it will be necessary to document and enforce how database schema updates are pushed from one environment to the next. My recommendation would be to update the new repository template for the source code control system. When a new repository is requested, include some examples of how database updates should be in source code control. Right alongside the “src” and “test” directories, I’d love to see “db.”
Debating process over results will never fix a problem. Database administrators must realize their customer is the application developer and the business. DBAs serve two masters; they must support the needs of the Agile dev team during releases while making certain the data is safe.
These may seem like conflicting goals (probably because they can be), but that’s the constant paradox DBAs live in. If a SQL script does not pass standards and the DBA team rejects it, that is everyone’s problem, not just application development’s. We no longer live in a “not my department” type of world.
Cory Doctorow infamously wrote, “The first casualty of any battle is the plan of attack.” As mentioned earlier, to demand that DBAs or devs perform the same task the same way because “That’s the way we do it,” is a recipe for failure. To put that in very real business terms, Netflix and Uber have taught us much about the video rental and taxi industries and how to respond to change.
Given the way the Agile Manifesto has changed development for the better, it’s high time for it to impact the DBA. They can be the agents of change or be forced to change. Personally, I always prefer the former to the latter.
Datical’s mission is to radically improve and simplify the application release process by automating database management. For more information, please visit http://www.datical.com/.