Seriously, I'm asking. I had this discussion with a colleague the other day, and it left me feeling unanswered, so I'm curious to hear some anecdotes.
I assume that since it's 2014, we are all using some kind of source control repository. One of the main reasons we have repositories is to keep our code safe in case something happens to our dev machine. If you didn't have a saved copy somewhere, having a hard drive failure would be catastrophic to your organization.
One of the ancillary features that comes with source code control is incremental history. As source code files are added, deleted, or changed, source control repositories dutifully keep a history of all changes, and they keep that information indefinitely. I have always assumed that was a good thing to have an indefinitely long history of all code changes since inception.
Now I'm not so sure.
At face value, the code history is about finding how things were in the ago, some indeterminate time in the past. They don't represent the production codebase of today (especially if you release features frequently). In a lot of agile shops, the code in them is stale after only a few weeks.
Some companies have processes that theoretically allow you to pick any date in the past and redeploy the entire system as of that date. You have to have code history to enable this. Unfortunately, despite unlimited rollback being cited to do any number of things in the software industry, it's rare that rolling back is actually plausible. DB changes, business processes, bug fixes that have been made since that date - those can all torpedo the idea of rolling back to some generic past date.
Maybe there's a legal case for keeping code indefinitely. I'm not aware of such requirements, but I can imagine that maybe certain industries/entities may require it. If it's a requirement for you, I give it a pass, although I still question what the actual benefit of digital hoarding is.
When I think about the uses I've had for code history, it's almost always been to research something that the team is certain was working at some point, and we have a new bug reported. The purpose of the research is to look at the history of the file and find out not only what change was made who made the change.
Why does who made the change matter? The only thing that you should really care about as a team (assuming you're all competent developers) is whether the code works, right? Something is broken, and we want to fix the problem.
One reason you might want to know who made a breaking change is to ask what the thought process was behind the change, and whether they have a reason that the change wasn't made differently. I've never seen this reasoning hold up in practice. Most often, the person responsible has implemented dozens of features since the one that's broken and doesn't have the slightest idea why something was done a particular way. Also, frequently, the person making mistakes can feel checked up on or targeted. Making team members defensive or concerned about not being valued or thought less of will not help the team.
Also, figuring out who made the breaking change has the effect of personalizing the code, when it's actually the team and the team dynamic that allowed the change to be made. We want to keep things as ego-free as possible.
So is it all about blame, then? Is that the only reason you would want to know who made a change? I'm on the fence about that. Modern development shops all have some kind of automated testing associated with their development cycle. While it is not impossible to introduce breaking changes into well-tested code, it should certainly be difficult. When implementing a new feature, if the code you're changing isn't already tested, it's your responsibility to get current behavior under test, and then introduce new tests for the new behavior.
Strong teams hold each other accountable for not mistakes, which are unavoidable, but for process. If there is an indication that, say, testing process was subverted, it's useful for a team lead to pull a person aside and say something like, "Hey, I just fixed a production bug, and it looks like you may have been involved with this code in the past. I noticed that we could have had better test coverage of the feature, so let's check out what I did to test this code. I'd value your insight, in case I'm missing something." It could be that the feature was urgent and the developer on the story was too afraid to ask for help testing. Turn the problem into a teachable moment without belittling or threatening and the team member levels up without fear.
I'm curious to hear what y'all think. Could you live without your source control history? Why or why not? What other uses have you had for digging into the ago?
No comments:
Post a Comment