Why “No Source Control” Is Not A Problem

Confused?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.

4 comments on “Why “No Source Control” Is Not A Problem”

  1. David V. Corbin Reply

    Not having source control is inherently a problem. Solving this problem may not solve all of your problems (in fact it is highly unlikely that it will). Avoiding source control thinking something else is a complete solution is sure to leave you exposed.

    A key element in audits (including the forensic type that occur during lawsuits) a failure to provide a documented timeline and state of all items during that time line is critical. The “what” (provided by Source Control) is the beginning. There is also the “why” (provided by integrated ALM practices tying every change to a series of work elements). Then come due diligence in terms of validation (provided by having associated testing results).

    • Gil Zilberfeld Reply

      Thanks David!

      Obviously, the post’s title is controversial in appearance. Although, technically having no source control is not a problem – it’s a decision. Not a good one, and very risky. And it can be changed. The post is about saying “there’s no solution”, when in fact we’ve already thought about the solution.

      Gil

      • David V. Corbin Reply

        Gil,

        Thanks for the reply. I have no problem with controversial titles, I use them myself .

        While I can agree with “not a problem – it’s a decision”, the “it can be changed” is not necessarily true. If information is (truly) lost, then it is gone and (unless time travel is available) the decision can not be retroactively “changed” and recovered.

        Let’s take a common condition. You backup the DB daily, retaining each backup for 3 months [approx. 90 versions] and then the first backup of each month “forever”. At this point (since SQL is not compiled) you already have a “Source control” system, albeit with very poor granularity.

        After this process has been in place for a long time, you are hit with a claim that “6 months ago (some date in the middle of the month) a ‘bad thing’ happened”.

        Examination of the recent backups will almost certainly reveal that changes during the month are a common occurrence. However for the point in time under consideration, only the 1st of that month and the 1st of the subsequent month are producible as evidence.

        At this point you are basically in an indefensible position and the material needed to provide a proper defense is long gone and unrecoverable.

        The only way (at least that I have found in my fairly long [40 year] career) is to have kept “real time” records with not only the state of the material, but also the supporting items (covered in my previous comment)

        PS: I also agree with making sure that the “solution” you are evaluating is going to address the problem(s) [past, current and future] that you are focused on.

    • lior Reply

      David,
      Just to point out that audits was not the problems they were trying to solve in this story.
      If the problem you are trying to solve is handling potential lawsuits, then it seems reasonable that you need something that will help you gather the data. (and source control may be a good way to do it)

Leave a Reply to David V. Corbin Cancel reply

Your email address will not be published. Required fields are marked *