Share via


Windows Confidential: Dusting for Fingerprints

The last person to touch a segment of code is ultimately held responsible for whether it runs properly.

Raymond Chen

There’s an unwritten law in software development: The last person to make a change to a line of code becomes ipso facto responsible for any problems traced back to that line of code. Even if all you did was insert a space after a comma or fix the spelling of a local variable, your fingerprints are on the code. When something goes wrong, the code police will come knocking on your door.

Most source-control systems have a tool that automatically identifies the last person to make a change to a file. It can also generate a file listing where each line of code is annotated with the name of the person who last modified the code.

In some projects, there might be a function or component that’s so problematic people avoid making any changes if at all possible. They fear having their fingerprints on it will have them put on the spot for the slew of problems ultimately traced back to that code.

So Long

One of my previous colleagues took this tradition of instinctively blaming any defects on the last person to touch a file and used it as the basis for a farewell prank. As his final act before leaving the team to join another project within Microsoft, he committed a change that spanned across hundreds of files. It touched every file of every critical component.

The comment associated with this massive change commit had the title “Convert to wide Unicode.” In the copious detail comments, he apologized that he was “able to convert a large part of the project, but not all of it.” The comment also explained what code needed to change throughout the project to finish the work. He also noted some “gotchas” that could be encountered.

The more you read the comment, the more you wondered what sort of insanity he was experiencing. The comment discussed changes to some fundamental constants like MAX_PATH, special compiler extensions to create stack buffers that expanded dynamically in place (shifting all other local variables to make space) and other crazy code changes.

The joke was revealed when you actually studied the files he changed. Every single file in the change was a null commit. He didn’t change a single line of code. The files were in the change set just for show.

This prank had lasting effects for quite some time, mostly due to its timing. Shortly after my former colleague perpetrated this joke, the project management team decided to create a database that tracked which developer was the primary contact for each file in the repository. To initially populate this database, they followed the “last person to submit a change to the file” rule. Because my colleague had recently submitted changes to every file in the critical components, nearly every file in those critical components ended up with his name attached.

For at least a year afterward, any person or automated tool consulting the database would send my colleague an e-mail when they found a problem in one of the files he modified. He would have to forward the e-mail back to his old teammates to ask them to take a look at it and update the database entry to refer to the proper owner. This was cosmic payback for inflicting his farewell prank in the first place.

Raymond Chen

Raymond Chen*'s* Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming and metaphorical parking lots.