Kendra Little

22 July 2020

When Signs of Trouble are the Norm: Identifying Warning Flags in Development Processes

This post is part of the Unicorn Project Read Along, hosted by IT Revolution. I’m a fan of Gene Kim’s work and I also love a book club, so it’s an irresistible combo. It’s not too late to start reading The Unicorn Project and join the conversation.

The Unicorn Project begins with a Senior Developer and Architect named Maxine Chambers being reassigned — under shady circumstances — to work on the troubled “Phoenix Project.” Maxine works at a company named Parts Unlimited, which has invested 20 million dollars so far in this digital transformation effort, but which hasn’t shipped anything.

As Maxine joins Phoenix Project, she finds signs of trouble…

A teammate tells Maxine that:

We don’t have a standard Dev environment that developers can use. It takes months for new developers to do builds on their laptops and be fully productive… In fact, we’ve had some new contractors on site for weeks, and they can’t even check in code yet.

The Unicorn Project, Chapter 1

Maxine is very concerned by this because of her experience. Maxine has “learned over her entire career that when people can’t get their builds going consistently, disaster is usually right around the corner.”

As the book continues, we learn a bit later from William, the Director of QA, that there’s no quick way for developer or build environments to get put together because “our teams are getting further behind on testing, so we agreed that in order to hit our dates we would deprioritize environment work — shipping fully tested features would take priority.”

What if the build doesn’t even exist?

Some people might read The Unicorn Project and think, “wow, my team is way ahead of that!”

But– are you really?

Don’t just think about the application components of your environment. Think about the other code you write, the code for your database. How long would it take to set up database environments for your developers? How long would it take a new contractor to get set up so that they were trusted to write a change that touched the database?

In the 2020 State of Database DevOps Report we found that databases continue to be impoverished when it comes to development capabilities.

Low use of version control for databases

We had more than 2,000 respondents to the State of Database DevOps survey this year. Of those, the majority do use version control for their databases, but it is only by a very slim margin.

Over the years of our research, we have seen the use of version control go up, but only very slightly — there is only a 3% increase in the use of version control in 2020 as compared to three years prior.

Version control provides huge benefits for development of all types, including database development:

• It allows changes to be shared in a clear, documented, organized way, with dramatically lower risk than sharing changes by other methods (file shares, etc.)
• It provides a lineage for changes and the ability to understand when something changed and by who
• It allows for identification of conflicts when multiple people have changed the same code, and methods to resolve those conflicts
• It sets a groundwork for early validation, such as builds and automated tests

Very few automated builds for databases

In The Unicorn Project, Maxine is alarmed by the poor documentation of the build, and the difficulty for a developer to be able to run one. But there is a build out there which some can run, although we learn that it’s prone to failure.

We find in our research that very few people have established build for their database code. I would hope that the number of those using automated builds for database code would be close to the number of those using Version Control for database code, but this is not the case —only 27% of respondents reported that they have the ability to build their database code.

Building code provides the ability to identify errors in code very quickly.

In my past life as a DBA, I worked with very smart people who worked to be agile — and I still repeatedly received database code that did not compile correctly in handoffs from developers to deploy to our staging environment. The reason for this was that we lacked the ability to build our database code.

Even fewer can set up database development environments quickly

A lot of Maxine’s troubles in joining her new team are related to problems accessing or setting up an environment to work in.

We find that like the team in The Unicorn Project, many have deprioritized environment work when it comes to databases. Only 21% of respondents reported that they have the ability to automate provisioning of databases.

The Unicorn project is right: high performers focus on core capabilities for productivity

Let’s compare the numbers we have seen regarding database development practices to this screenshot from the 2019 Accelerate State of DevOps Report (DORA/Google)

Accelerate State of DevOps Report 2019, by Google / DORA, p60

The Accelerate Report shows that automated builds are a core practice, and that high and elite performers almost all have this capability.

However, the Accelerate research just asks about builds in general, and doesn’t ask if builds are in place for all types of code. My interpretation is that the folks answering this question as part of the Accelerate research are primarily thinking of the builds they have implemented for application code only.

In other words, folks are so used to the state of database development being bad that the problem becomes hard to see. It is simply normal.

This is a huge opportunity for those in competitive markets

My intention in this post isn’t to shame anyone or make anyone feel bad for not having modernized their database development practices.

But like we see with Maxine in The Unicorn Project, you can be depressed by the state of this, or you can take action.

Another way to look at this is that there is a huge opportunity to improve the quality of your database code, and the speed at which you can deliver it. You can make database environments quick and easy to create. You can even make it so that new team members can get up and running the same day they begin on a project. You can create processes and workflows that empower them to safely become productive right away.

I’m looking forward to reading more of The Unicorn Project and seeing how Maxine and her team make things better at Parts Unlimited.