Be a Team Player

I have to admit that early in my career, my approach to source code control was less than team-friendly. In addition to simply having a source code control tool in place, you should make sure that every operation that you do with it causes the minimum of inconvenience to your colleagues.

At my first job as a Software Engineer, we used the Unix-based Source Code Control System, SCCS. It relied heavily on locking to ensure that developers weren't tripping over each other, by preventing them modifying the same files at the same time. This was a problem, because we often needed to modify the same files at the same time in order to work on different things concurrently. Our solution was to either twiddle our thumbs waiting for the developer to release the lock on a file, sometimes by committing a half-finished change; or to take a copy of the file, chmod it to become writable, edit away and worry about manually attempting to merge the other developer's changes in later. No matter how hard we tried, we still had instances where we overwrote other people's changes inadvertently. This is why your team needs a decent source code control tool which supports automated copy-modify-merge instead of locking.

But it wasn't just the tool that was the problem; it was also the way I used it. When I was developing something new, I always wanted it to be perfect before committing it to the source repository. I would add feature after feature, without checking anything in. My boss was very pleased with my progress, but was so nervous that I'd lose the work I was doing or would break it in some way, that he would beg and plead with me to check it in. “I will, but it's not quite ready yet”, I would say. The point I was missing was that it didn't need to be perfect before I checked it in; it just needed to be better than what was there before. I should have been checking in each time I added a new feature, or fixed some bug.

Early in the development of a piece of code, it tends to be in a rapid state of flux, and sometimes it's not entirely clear when things should be checked in because you're adding so many feature so quickly that committing every single one would be a waste of time. One other reason I was hesitant to check in was that we used SCCS log comments in the headers of all our files, and these grew every time a file was checked in. After a while, the log comments dominated the actual code; yet it was the code that was most important because it defined what the software did; not the ever-growing log comment header. Some developers liked having the history right there in the file, but I hated it. And I hate it even more now. If you want the history, look it up in your source control tool; it's all there. It's not the history of a file you really care about as a developer; it's the current state of it and it's current design.

But I'm making excuses here. Nobody else could benefit from the changes I had stashed in my private sandbox, until and unless I checked them in. I was still studying Engineering part-time at the time, and would head off several evenings each week to lectures. My boss got so nervous that he would get one of my colleagues to check my changes in while I was in my lectures. I'd come in the next day to find my half-completed changes checked in; and I wasn't happy about it. It really wasn't his fault though; the solution was for me to check in complete changes as I went, so that we had an evolving codebase in the source repository with monotonically increasing functionality. That way my boss would get to sleep at night, and my colleagues would get access to my work in a timely manner.

I'd like to say I learned my lesson, but there were other lessons still to learn on this front. At my next job, the team were using RCS, an open-source source control system similar to SCCS. And like SCCS, it used locking. I came across CVS which added an automated copy-modify-merge system around the RCS core, making locking and the inevitable nasty workarounds it requires a thing of the past. I loved it, and managed to get it introduced at the company. I also got used to checking things in more frequently; like every time I made a single logical change to a set of files. But I still had problems with big changes; somehow they always seemed to coincide with me going away on holidays for weeks at a time. There I would be on Friday afternoon, feverishly running the regression tests to get them all to work before committing my change to a stack of files and heading off to laze in the sun for the next few weeks. Sadly, my hapless colleagues were less fortunate; they had to deal with the fall-out from a large change, having no idea what I had done or why. The history was all there in the CVS archive, but ploughing through another Engineer's changes to try to work out why the build doesn't work any more, or trying to infer what they were thinking from a hasty commit comment is not exactly the fun side of Software Engineering.

The moral to the story is to always consider the impact of a change on other developers before you commit it. Certainly you should never intentionally break the trunk version, but you should also make sure that your changes are self-contained, self-explanatory, and structured in a way so that other developers can update their sandboxes at any time in the process, without having to know what it was that you were up to. Team communication is important, but the less you need to tell other developers about your changes in order for them to keep working efficiently, the better. If you find yourself emailing around to tell your colleagues about your latest mega-change, consider that perhaps you haven't made the change in as smooth a manner as possible. And don't check changes in on a Friday afternoon before going on holidays because something is sure to break. You want to be remembered for what a great engineer you were, not for the pain you caused your colleagues while you were off camping in the mountains after yet-another Friday night mega-checkin.

---

Social Bookmark this page: