Tuesday, October 2, 2007

Best Practices: Does anyone here want to learn anymore?

I have been having this running argument with a couple of the other developers where I work. A couple of them believe that the best way to use source control is to keep the working code in the trunk. That's not the part that we argue about. Then the first time the code is pushed to a production environment, the code is branched. So far so good... well... sort of. The problem is that there is not enough isolation around the branch. It's OK to only have one production branch, but it should be isolated from the development branch by another level. This is called forward integration by some. Or the branch can exist on its own and bug fixes from the branch move to the trunk. When a new version is ready, a new branch is created and pushed. Either of these approaches would rid us of the following trials and tribulations.

What actually happens is that deployments go something like this. One person resolves all of the conflicts for the past four to six months in order to merge the trunk directly into the production branch. It takes this person somewhere between two and four hours when we're lucky to hopefully accurately resolve all those version conflicts. I certainly hope he remembers all the changes and their far reaching effects that I made six months ago, because I don't. On top of that, no one can check in any changes while this is going on. In my years of developing I have used five different source control systems and two of four different techniques that I am aware of for branching. Not a single one of the utility manuals or forums ever suggested that merging the trunk directly into into the production branch as standard operating procedure was a best practice for using source control.

I try to explain all the subtle reasons why one of the best practices will work better. Why it is better to merge bugs as soon as the fixes are made (smaller pieces of work, merged by the person that made the change while the code is fresh in their mind). How this allows for faster, less error prone code pushes. The reasons why isolating the branches makes sure that people are not getting in each other's way. There are many more reasons why one of the documented techniques will work better in the long run, and all of those reasons are in the source control user manuals. "Don't listen to me talk about source control if you don't trust me. Just read the books and you'll find for yourselves all the good reasons to follow the best practices," says I.

It just seems like no one wants to understand. Even on those rare occasions when a book is cracked or the web consulted. It seems like people just look at the examples without reading about why things work the way they do. Says one of these developers, "I saw this great piece of code on the web today that dynamically hunts through all the configuration files in a directory looking for a particular section. So I implemented it." Sigh... "Great," says I. "What you failed to read is that it probes through many directories looking for one particular file by name, not one section in all of the files. Now we can not have multiple configurations in the same directory because only the configuration section from the first file will ever get read."

Maybe the problem is not that people don't want to understand. Maybe they have actually lost the ability to reason things out:
"Here's all these great reasons, let's change how we do stuff."
"Show me how that works."
"That will take two weeks. Let's just talk about it so I can convince you."
"If you can show me a better way, I'll consider it."
"OK I'll get started on that tomorrow."
"Two weeks? Are you crazy? We don't have time to do that! We don't even know if it will work!"
"Then let's sit down and I'll show you how it would work. It's not that hard to understand. Really."
"You better show me how that works first."

I kid you not. Why are people just not willing to sit down to talk and truly grok a concept? I don't think anyone has lost that much brain power. It cannot be that reading is too difficult. Maybe they just got ground down. I know justifications with as much common sense as the preceding conversation come down from on high all the time. And to be fair, it does seem to be the more senior members of the team that need to interact with the powers that be more often that are afflicted by this apathy. I bet they are getting trained to not care because they are in a bad environment. Then again, it could be that age is setting in. The younger guys on the team right now really seem to be hungry for information. And the young ones that are left go out of their way to know all all those new concepts. Biblically almost. If I wasn't such the optimist I'd think I was being deliberately stonewalled. Wait a moment!?!?

I love learning about technology. Both through conversation and reading. Speaking has the advantage that, if the other person's message isn't clear the first time through, they can rephrase their point. Books just aren't good about rearranging the characters on the page when a new approach is needed. But I love learning new things from all sources. It's especially gratifying to have that "Aha!" moment when true understanding slides into place and I see just how much more productive me and my team could be. Unfortunately, as of late that feeling turns rapidly to frustration when those I need to convince won't listen to reason or read the books.

I suppose there's always that chance that we just don't have time to make those changes I'd like to make right now. But if that's the case. Just say so. I can learn that much easily. I realize that this is a cry for help. Maybe in more ways than one. But I really want to understand what I need to do in order to engage those brains once again. Help me learn how to help them learn.