How to annoy your teammates

In 3 easy steps:

Step 1: Perform a change that affects many, many files

My favorite is a namespace rename.  Other choices include deleting a core marker interface, renaming a layer supertype class, or changing the folder structure in a project.

Typically, VisualStudio will crash when I do this, though I’m not sure if it’s VS choking or ReSharper.  Either way, a large automatic refactoring will cause a crash.

Step 2: After the VS crash, re-open the solution and choose to recover all unsaved files

ReSharper likely made it quite a ways through your refactoring before VS crashed.  All those unsaved files were likely cached for recovery by VisualStudio, so you can probably get a lot of those changes back.  Instead of choosing to revert your local changes, go ahead and recover all those files.  It’s key for maximum annoyance.

Step 3: Merge these recovered files back to trunk

Since this was an enormous refactoring, maybe affecting hundreds of files, you’ll want to merge your changes back to trunk as soon as possible.  After all, you don’t want to be the sucker merging after everyone else has finished their work.

When you’re done, your co-workers will be greeted with one annoying merge, and another fun dialog that never seems to quite go away:


Just when you think you caught the last of the recovered files that had its line endings screwed up, another one pops up.  They’ll hate you once because of the core change that affected so many files, making it quite annoying to merge back to trunk.  But they’ll form that long-lasting, persistent hate because of this dialog box that keeps coming up.  Yes, there is that little checkbox at the bottom, but who reads these things anyway?

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • You forgot one more “how to” … use VSS or TFS during this process.

  • I know it is wrong and that I should use a branch for it, but when these types of changes needs to be done I like to wait until my coworkers are not in the office anymore. Saves a huge deal of pain.

  • I have another one

    1) Let your team mates use a lot of time populating a test database

    2) Connect with NHIbernate and use SchemaExport to drop all tables.

    3) Wait for them to fix it

    4) Do it again

    I promise it will do the trick

  • Out of curiosity, how large is large when you say a any refactoring causes a VS crash?

  • @Hadi

    Somewhere in the 100+ file range for something like a namespace rename.

  • grundt


    Could you please expound on your comment: “… use VSS or TFS during this process”

    I suspect you’re alluding to a performance issue, and I’d appreciate if you would confirm that.

    ( We’re a shop where everyone works remotely over a VPN. Years ago, we converted from VSS to SVN, and everyone has been quite satisfied with it. But our newly hired “Scrum manager” is insisting we need to switch to TFS and that performance is on par with SVN )

  • @grundt

    I hate getting into the whole TFS vs SVN debate, but my experience with both has been that SVN is a zero-friction tool, while TFS introduces friction. My guess is that your newly-hired manager loves reports, and believes that mounds of reporting that TFS can give you will help him do his job better.

    If he wants a process reporting tool, my suggestion is to not chose a tool that locks you into a specific process. TFS is very hard to change your process after you start a project, and it’s rigid in its definition of a project. Look at a bunch of process reporting tools, including plain ol’ Excel (which works absolutely fine for us, a multi-million dollar project with dozens of team members).

    TFS is quite invasive to your daily development routine. From the “server always needs to be up” to the issue where every. single. task. requires network chatter. Because SVN keeps change info on the client, the only time you have to contact the server is for commits/updates.