Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Agents of Change and Enablers of Change

A good manager is an enabler of change. Once they find out that their team has a problem they do what ever they can to resolve it. They fix the process, they get the tools, they deal with the bureaucracy... what ever it takes.

What the manager needs on their team is one or more people who will be an agent of change. People who will be actively looking for problems and places where there is room for improvement and identifying them.

New people who come onto a team tend to be passionate, exited and sure that this time they're going to be part of a team that's going to do it right. Over time these passionate people, if not encouraged and valued by their manager, will become just another member of the status quo.

Too often I see teams who are bogged down in the status quo... the way things are. They fought those battles before and lost. They struggled with the bureaucracy and lost. They tried to do things right and were told "just do what you're told". Eventually they quit fighting the system.

If you're a manager, be an enabler of change and look for and encourage agents of change on your team. Find the people who are passionate about doing things right -- and don't let them get bogged down in the status quo.

Problems with wiki's in small groups

At previous employers I have suggested the idea of a Team Wiki and have never been able to get one implemented. I had bought into the concept so thoroughly that I assumed if I could ever just get approval then people would quickly see the value and start using it.

So when I brought the idea up at my new job I was very surprised to hear that it had already been tried... twice; And people didn't use it. It seems the main problem was that there was limited collaboration because the team was small and segmented (not a lot of duplicated work/roles).

It's a lost opportunity because one of the best times to implement a wiki is when you first bring someone on board (like me). Then every time they ask a question you have them document the answer for you and you review it to make sure that they understood. When the next new employee starts then have them search the wiki for answers before asking questions. If the information there is hard to understand or wrong, have them clarify or correct it.

The biggest benefit of having new people do the documentation is that they will get the details that are ignored by those who already know the system (because once you know a system everything seems intuitive and obvious).

I'll have to put some more thought into how to make wikis successful in small groups. In the mean time I've started documenting the details myself before I get too used to everything; maybe I'll get the chance to turn that information into a wiki yet.

How to Revert/Rollback a file using Tortoise SVN

It appears that a lot of you are finding my previous post about Revision Control Using Tortoise SVN when looking for how to Revert or Rollback a file using Tortoise SVN (at least per keywords in Google analytics). So I thought I'd throw this out right quick to help because I didn't cover it there.

As you probably know Tortoise SVN integrates into the explorer so that right clicking on a file lets you drill down into a ton of menu options. Not all functionality is deployed through the menu though; a lot is done through the Log. To roll back a file, start by right clicking on it and selecting Show Log.

Once you have the log open, right click on the desired version of your file. Your options will let you view this version or compare to your working copy (I highly recommend configuring Tortoise SVN to work with Beyond Compare if you have it; Settings/External Programs/Diff Viewer). The menu item that you want is "Revert to this Revision".

Upon selecting this Tortoise SVN will notify you that it is doing a reverse merge into your working copy; click yes. You will note that your file has been reverted/rolled-back and is showing as changed (red dot on icon). Commit the file (or make changes and commit) and you're done.

Hope this helps.