And thankfully nothing remains quite the same.
This month, I have been the DRI — the Designated Responsible Individual — at work. Fancy title. So what? I’m responsible for keeping a team-specific branch in our source control system in sync with the main branch. Don’t worry if you don’t understand what that means. I’ll explain it a bit.
Every piece of software that you use, from your Web browser to your favorite game to your operating system, starts out as source code: a set of instructions that tells the computer what to do. We’re all familiar with the idea that computers only understand binary code – a bunch of 1s and 0s. But it’s terribly hard for humans to write a meaningful program in binary. So we have programming languages: C++, Java, C#, PHP, Smalltalk, Python, Ruby, Scheme, and many more. These let programmers write things like printf(”hello world”); rather than a long string of ones and zeroes. In order for the computer to understand printf(”hello world”); the source code needs to be translated for the computer. That translation from source code to something that the computer can understand is called compiling.
Developers need to keep track of the changes they make to source code. Sometimes they make a mistake and need to go back to an earlier version. So they use a source control system that remembers all the changes and lets them get to any version they want. Source control systems are important when there is more than one developer writing a program. The source control system lets the developers share code with each other in a reliable and automatic way. In a typical design, there is a central server that stores the master copy of the source code, and then each developer makes a copy of the source code to his computer. This is checking out the source. Once a developer has made the changes she needs to make, she sends the changes back to the server — she checks in her source code.
Even simple programs may have dozens of source files and big programs like Microsoft Office or Windows have hundreds of thousands, maybe millions, of files, each with hundreds of lines of code. Add hundreds of people making changes to this source tree and you need a lot of machinery to keep things from devolving into chaos.
One of these mechanisms is called branching. It’s a way to segment the changes so that only a few dozen developers, say, are making changes that directly affect each other. Start with the source tree and make a copy of it on the server. Now there are two copies of the code. One team works in one branch, and another team works in the other branch, each making changes. At certain times, the teams need to synchronize their changes so that they’re working from a common base again. This synchronization is called integration. When the changes move from the primary, or main, branch, to the secondary branch, it’s called a forward integration. When changes move in the other direction, it’s called a reverse integration.
There are a whole set of ways to verify that the changes in one branch are ready to be moved into the other branch, and to verify that the integration is successful. The first test, though, is whether the code will build. You can think of building as compiling the source code, although it’s more complicated than that. There are many pieces of source code, and those pieces depend on other pieces in the system. So the build system has to compile the source code in the right order. In some cases, developers haven’t written the actual source code, but have instead written source code that will generate the actual source that gets compiled. The build system needs to manage this. There are steps needed to link all the compiled files into an executable that the operating system knows how to run. And a whole lot more. If the build system can successfully do its job, one step is out of the way.
But simply building doesn’t mean that the program actually does the right thing. You can compile a program with instructions that tell the computer to delete every file on the hard drive. Unless you’re a malware author, that is not a feature you want in your program. So there’s a second step: verify the build. This is done with a set of tests called build verification tests (BVTs) that make sure all the features of the software program work. There’s a lot more involved in testing, from automated functional testing, to stress testing, to performance testing, to ad-hoc testing, but that’s for another time.
Now, finally, I can explain what it is I do as the DRI for the month of February.
Every night after work, I spend a few hours integrating changes between the main branch and our team’s branch. I merge the changes from one branch into the other, build the source tree, and run BVTs. If all is successful, I check in, then turn around and pull changes in the other direction — a nightly reverse integration and forward integration.
I’m not constantly working during those hours since much of the time I just start a program and waiting for it to finish, but it requires enough of my attention that I can’t go out to a movie, for example (unless I want to stay up very late).
That’s on a night when things go well. If, after the integration, the build doesn’t complete or the BVTs don’t pass, I can’t check in the changes. Instead, I have to track down the owner of the tests and/or the code that’s at fault (I do a bit of investigation to narrow down the problem), give them a pointer to the build (that’s the result of compiling the code) and the enlistment (that’s the copy of the merged source used in the build) so that they can investigate the problem and figure out a fix.
Sometimes, there are big changes that need extra work — a more involved build than normal, for example — and thus extra attention to the process. Sometimes, due to the timing, a change happens in one branch and another change happens in the other branch, and, though each branch builds fine on its own, when they’re combined, the result won’t build. It’s why they have a person doing this work rather than automating the whole thing. We have a lot of developers working on a lot of code.
So — finally — what’s the attitude and how did it change?
Before February, I couldn’t help but resent the responsibility. Not only did I have to do my normal daily work, but then I had to do this DRI stuff, too. Never mind that every developer in our team does it at least once. I tried to convince myself that I would learn from this, but the resentment ate away at that approach.
On my first night, I was terrified. There are hundreds of people who depend on this source code — if I make a mistake, they’re all blocked. I had never done this before. What if the directions are incomplete? What if I discover something that isn’t documented? What if I’m just not able to do it?
After a few nights of success, I wasn’t as worried any more. I even relaxed a bit and started to write down the things I was learning as part of the process. The variety surprised me: from working with test automation tools, to the configuration and behavior of the autobuilders, to a way to write subroutines in a .cmd file. And, of course, I developed a confidence in our complicated build system and — for the first time — a sense of the overall shape of our source tree.
We’ve had problems. When I started, our development manager told me I had drawn a tough month. I thought it wouldn’t be so bad since I had gotten the shortest month of the year. But he was right. There were breaks after merging the branches, and there were some big changes that required a lot of effort, patience, and painstaking attention to detail. I spent time on weekends and got behind on my “real” work while trying to solve the DRI problems.
But it’s those problems that have washed away the resentment and let me grow. If the month had been normal, I wouldn’t have learned half what I did. I am more confident and enormously more useful to the team after doing this.
And I’m so much happier.
I will be relieved on the first day of March, but I’ll be a little sad, too. Even though I feel a heavy pressure when things aren’t working, and I worry every night until the tests finish, the joy of completing a complicated integration and the enormous satisfaction of doing it well make it worth it.
Dawn tells me that I thrive on challenges. And yet in the past couple of years, I have tried to create processes to smooth out the bumps in my environment. I’ve tried to create predictability and a regular routine. Somehow I got onto the mistaken idea that I would be happier if work were predictable and I could avoid surprises. But I don’t learn in those situations. I don’t build an emotional connection to the team, to the work, if I already know what to do before I need to do it. With unexpected problems, the need to figure things out that I’ve never seen before, and pushing hard to meet a deadline, I build a commitment to the people and the product, I engage my mind, and I learn.
And I’m well and truly happy when I am learning.
Tags: challenges, growth, software, development
del.icio.us tags: challenges, growth, software, development