Each organization in a company has its Favorite Application. It’s not truly their favorite application; it’s just the application they must use in their particular capacity in the organization. Stand up right now and walk into an unfamiliar part of your building and stalk your coworkers. If someone stops and asks you what you’re doing, tell them, “Rands sent me,” and vigorously nod your head. That always works.
As you walk the hallways of this strange new part of your organization, look at their screens. What’s the consistent application sitting on their monitors? Is it Excel? Well, you’re probably in some area of operations. Are you seeing a lot of Word? Maybe legal, possibly tech pubs. Is the cube empty? That’s sales.
The most common application in engineering is an editor . Whether it’s a terminal window or the world’s fanciest integrated development environment, their Favorite Application is a code editor, but it’s not their secret weapon. That would be version control.
The concept behind version control is simple. It’s a central network repository for all the files of which a project is comprised. If I want to edit a file, I run a tool (which works alongside my editor) that makes a local read/write copy of that file on my system. I make my changes and then, using the same tool, I check in my file to the network. So, what’s the big deal?
Usually, there is no deal. You merrily check in and check out your files with no fuss. The deal occurs when you realize that software projects are often massive collections of files that are edited by teams of people. A version control system solves the problem that occurs when two engineers have checked out and have changed the same file at the same time. Whoever checks in their changed file first has no deal. When the second one checks in, that engineer receives a message that warns, “Hey, this file has changed while you had it checked out. Whaddayawannado?” The user then gets to figure out how to merge the two files into a consistent working whole.
That’s version control as a traffic cop and that’s cool because it prevents folks from bonking each other on the heads, but I haven’t gotten to the major cool, and that’s the other thing I do when I check in. I don’t just check the file in; I also include information about what I changed:
“Rands added a new blingleforth function . It rocks.”
The version control server then copies my new version of the file up, tags the new version with my name and my comments, and increments the version number associated with the file.
Let’s ignore the useful fact that every single version of the file is stored in this system and focus on the comment I included with this change. This is the big deal. This is the secret weapon in engineering. We not only save every version of our work, we also capture the context of the change. Version control stores the thoughts that made our ideas bright.
If you’re thinking, “My, what a quaint nerd custom,” if you’re not having a clouds-are-parting moment, think about two products: del.icio.us and Flickr . Both have built their feature sets around capturing context, and by context, I do mean tags. Each time someone adds a new link or photo to these services, they can add whatever tags they like. No rules. Just start typing words regarding what makes the link or photo relevant. That’s context.
When you start stumbling around Flickr and del.icio.us , you realize the value that is created when people choose to capture and share the context of their content. At the South by Southwest Interactive conference in Austin, I was in awe of the folks who were taking the time not only to capture and upload their photos to Flickr, but also taking the time to carefully tag all their content. Thirty minutes after a presentation, there were dozens of tagged pictures sitting in Flickr for the presentation I just watched.
So What?
Think of the big project you’re working on right now. For me, it’s this chapter I’m merrily typing away and hitting the Save button every 12 seconds because I’m a twitchy saver. Comes from years of flaky Windows applications that liked to crash. If you save a lot, you’re not screwed.
When should I capture context on this project? When should I stop and capture the thoughts about what I just wrote? Whenever I’ve created significance. I’ve been keeping track of these moments while I’ve been writing and so far. They are:
New intro down , borrowed from version control article I can never seem to finish.
Removed Wikipedia from example technology—Flickr ’n’ del.icio.us are enough . . . don’t confuse them with wikis.
Keep moving disclosure paragraph around . . . haven’t found a home, yet. Might be wrongly in love with this paragraph.
Do these comments matter to you? No. Do they matter to me? Yes. Do I want my favorite editor to prompt me every time I hit the Save key for context? No. I want another verb, let’s call it wow, and let’s have it mean, “I’ve done something significant to my project and I want to capture the context of that change.”
This is not an obvious activity for most people. In fact, huge passive-aggressive battles have been fought within my engineering teams over these change comments. It’s a fight between those who are lazy and just want to check in their files and those who know that, while having the code safely in version control is good, understanding what is happening to the project on a day-to-day basis is even better. It’s called a status report .
That’s right; I finally found my technology angle on killing status reports. We need our tools to allow us to capture context at the moment we’re being bright, not Friday at 4 p.m. when we’re trying to get the hell out of work. How much easier would your status report process be if all you had to do on Friday afternoon was ask your favorite app, “Show me all the wow for the last week”? That report alone is enough incentive for me try to remember to record my wow among all my twitchy saving.
Nerd Disclosure
I’m serious a version control nerd. At Borland, I was the junior engineer, which means I was saddled with building the product duties. This means if the product did not build, someone yelled at me. This gave me a strong incentive to build an application that forced each engineer to make a comment, no matter how small, each time they checked into the project. It’s not me. It’s him. At Netscape, I watched in awe as CVS was merged with bug tracking and build systems via primal web applications. I still drool over Tinderbox . At my startup, I was the guy who took Microsoft SourceSafe out behind the building and kicked the shit out of it.
I live and breathe version control because I see the value. Each year, I learn more about more Favorite Applications. I learn how executives live and breathe presentation software. I learn about the magic that those folks in operations can coax out of Microsoft Excel. Everyone is hard at work creating stuff, and, with some minor tweaks to our Favorite Apps, we can wrestle version control from the nerds and help everyone index their brightness.