Because having source control is a solution.

Sometimes we get fixated on something that’s missing, and we’re sure that’s the problem. When we can control it, it really isn’t a “real” problem, because it’s easily solved. But in many cases, the solution is out of our control, and we think that if only we had that missing piece of the puzzle, the problem would be solved.

An example would be handy right now

In a retrospective this week, I asked the team to put out all the major problems that plague them. Some problems were described using the form of “No X”. However, when something is missing, that is rarely a problem. The actual problem is the effect we observe.

The team state one of the problems as “No source control for databases”. I asked what the effect was, and got to “We’re investing too much time in deployment”. With data that proves it .

First of all that’s an actual problem statement: Too much of X. Not enough of Y. Can’t do Z. These are problem forms. It’s how our life and work are affected, and there’s some root causes that lead to that problem.

When I hear that something takes too much time, there’s some automation missing. Because the team doesn’t have source control for database schemas, they can’t automate the deployment, and therefore deployment takes too much time. Sounds reasonable, right?

But there’s a catch here: If we’re sure that putting all schemas under source control will solve the problem, we might be missing an alternate solution. Are there other solutions?

The Others

First we defined the problem again around the effect that was felt – too much time spent on deployment. We decomposed the deployment time into 4 parts: Actual deployment, monitoring (that nothing from before was damaged), testing (that the new functionality works in production) and code review.

Code review at this stage? Wasn’t it done before?

Of course it was. But because the team was not sure that nobody changed the code, schema and data between the code review in development and now in production, or that someone else had published new code and schema in that time, the team goes through code compare at that late stage.

Turns out that’s where the major part if the deployment time goes.

So the team is being cautious. Maybe too much?

While they fear the repercussions of a deployment problem, the chance of an actual database problem is very low, specifically at their cadence. We’ve decided to do an experiment – rely on the code review in development and drop it at the deployment phase. We’ve relied on other teams doing that and not too many problems happening there.

Problems can have multiple solutions

Having a database source control solution will surely benefit the team in many ways. It may also reduce their fear of making a deployment mistake, and will help with automation. It will probably lead to cutting down deployment time.

But it is not the only solution. It’s a solution, and maybe there are others that are simpler, easier and faster to try and get their benefits.

Next time you say the problem is the missing X, try to go through this process –redefine the problem, decompose and think of alternate solutions.