InformIT recently posted an interview with Scrum evangelist Mike Cohn. The interview has a lot of great information and hits on a number of points, including the benefits of user stories and agile estimating, and some of the reasons why many companies fail to successfully transition to Agile.
Check out the interview here.
One of the best practices around source-control is the idea of checking in code frequently. “Frequently” is, of course, a relative term. Some take this to mean checking in code within a matter of hours; others, days. Some suggest check-ins should occur every time a new feature is added. Then the question becomes: What constitutes a feature? Is a method of a class a “feature”? Is a class a “feature”? Is a feature based on a user story? A Use Case? A bulleted item in a requirements document?
For me, I’m prescribe to the practice of checking in per feature. And, by feature, I mean a Use Case (or a single flow of a Use Case), or a backlog requirement. Of course, some features take more time to implement than others. But this is ok. Sometimes, I’ll check in within a couple hours. Other times, I might check in after a couple days. Rarely, however, do I leave files checked out for more than 2-3 days (if that gives you an idea how “large” I spec these features).
One of the many benefits of checking in frequently is that you allow the ability to rollback in-progress code changes that are not panning out. For some of you, this may be a completely foreign idea. ”Delete my code?! Are you loco?? This code was spawned from the magnificence that is my brain. It is precious.”
If that was your reaction,… well, if that was really your reaction, then you should probably stop reading. Wait, don’t stop reading. I need the subscribers… For those of you that had a bit more subtle reaction, consider this anecdote:
This morning, I was coding up a new feature for an active development project. All previous code had been checked in before starting this new feature, so I was starting from a stable build. Starting out, I was trying to figure out the best way to implement this new feature. In some cases, some up-front design and modeling would have been useful – but, in this case, where I was working with a few unfamiliar .NET classes, it made more sense to just try out a few different approaches programmatically and get a feel for which worked best.
In the span of about 90 minutes, I had implemented – and subsequently rolled back – five code changes before finding an approach that finally worked.
Some of the reasons for rolling back the first several changes included:
Also while making these development changes, I noticed Visual Studio modifying a number of auto-generated files that I don’t normally touch (including project, .settings and .resx files). It would have been very difficult, if not impossible, to go through these files manually and find all the changes that were made. But because I was rolling back all of the files via TFS, there was significantly less risk of introducing unstable code (or accidentally leaving leftover code) in a later build. It was also considerably faster than manually traversing the code for delinquent code.
If you’re not accustomed to rolling back code in your development cycle, it’s feels kind of like this:
So if you are (or know someone who is) in the camp where code check-ins are almost an afterthought, consider this example and think about the value that frequent check-ins can add to the development cycle.
Disclaimer: Rarely do I get a chance to totally geek out and write a post specifically about code. I enjoy the change-up. And hopefully some of you will benefit from this.
Ok. On a recent project, I’ve been playing around with the .NET APIs that were made available for interacting with TFS. You can tell that the documentation for these API’s are a little more raw than what is available for the .NET framework components, but that is not to say they aren’t still helpful.
As part of my project, I needed to programmatically download files to the local machine from version control. As part of my unit testing, I wanted to validate the source path before attempting the download. Basically, I wanted the equivalent of the System.IO.Directory.Exists() method in the .NET framework, but that validates against version control.
After several minutes of searching, I found the VersionControlServer.ServerItemExists() method. This handy method basically combines the functionality of the File.Exists() and Directory.Exists() methods, switching between the two (or combining) by setting the custom ItemType enumeration.
Using this method, I can first validate the path, as the following example shows:
Dim fakePath As String = "$/MyFakeTeamProject/RoadToNowhere"
Dim vcServer As VersionControlServer = Nothing
'...initialize a reference to the version control server here...
'Perform validation against server path before downloading.
' This example works for both file or directory paths.
If Not vcServer.ServerItemExists(fakePath, ItemType.Any) Then
Throw New Exception("Hey! The path you gave me is bunk!")
End If
…and for the C# folks:
string fakePath = "$/MyFakeTeamProject/RoadToNowhere";
VersionControlServer vcServer = null;
//...initialize a reference to the version control server here...
// Perform validation against server path before downloading.
// This example works for both file or directory paths.
if (!vcServer.ServerItemExists(fakePath, ItemType.Any))
{
throw new Exception("Hey! The path you gave me is bunk!");
}
One of the things in TFS that has been of little value to me is the “Latest” column, found in the Source Control explorer. The intent behind this feature is a good one: Be able to easily tell if you have the most recent version of a source file, or if somebody has checked in a new version since you’ve last pulled down code. But somewhere between idea and implementation, something got lost.
View of Files in the TFS Source Control Explorer
There’s an annoying little side effect to this feature. If the developer decides to make changes to files outside of TFS – for example, deleting local files that are no longer worked on – TFS will not recognize that the developer no longer has the latest version. This becomes very irritating when trying to re-download the files using GET LATEST. Because TFS thinks you already have the files on your local machine, it will, by default, skip downloading the files.
Fortunately, Martin Woodward posted a solution on his blog a while back on how to correctly clean up your local files while, at the same time, keeping TFS in sync. I consider this to be a bit of a hack, because it seems very unintuitive. However, I haven’t seen any new features in TFS 2010 to lead me to believe that a more intuitive approach is being added. So, either Microsoft isn’t getting much feedback on this, or they consider Martin’s approach to be the preferred approach…
Meanwhile, I’ve since found myself doing this somewhat frequently after finishing projects, in order to keep my local directories from piling up with old files that I no longer need.
Agile Purists beware: The following post may cause uncontrolled vomiting, convulsions, gnashing of teeth or “soap box”-style ranting to anyone who will listen.
Alright, now that we’ve got that out of the way, let’s talk about that headline!
At work, I’ve just started working on a small three-person project to build a relatively simple Windows application. Two of us on the team serve the roles of project manager/ScrumMaster, Business Analyst and Developer. The third serves as our customer/acceptance tester.
Last week was our first week of our first two-week iteration. Our “customer” was on vacation for part of the week, but we held our planning meeting ahead of time so that the other two could move forward and have something to show our third when she returned. We implemented daily scrum meetings, but found them to be a bit excessive for just two people. So, for part of the week, we held our scrums over an Instant Messager.
I asked myself this question at first. One of the tenets of the Manifesto is the idea of “Individuals and Interactions over Processes and Tools”, with the implicit supporting argument that face-to-face communication is the preferred approach. However, remember that these ideas are not absolute. We do not have to promote individuals and interactions by sacrificing our ability to take advantage of technologies and tools. Instead, we should take advantage of tools and processes where it is beneficial to do so.
In our case, myself and the other developer sit on different floors. Rather than walking to a separate floor for a 2-3 minute meeting every day, it made more sense to take advantage of a tool, like a phone or instant messager.
Now, I’m under no illusions that this is a good practice in general, nor that it should become a recommended practice at large. While there were some benefits in our specific case, this practice would quickly become unweildy as soon as we start adding more people to the daily scrums. Even with three people, I feel like more could be accomplished more efficiently if we met face-to-face (or, at the least, over the phone).
The point I want to get across is that we need to remain pragmatic in our approach to software/solution development, and not fall into the trap of following any manifesto, principle or practice so blindly that it becomes detrimental to the team. It’s up to us to decide what makes the most sense for our specific situations.
Scott Hanselman posted a great interview with Roy Osherove over some best practices around unit testing. This was a great interview and, if you’re interested in unit testing, I highly recommend you set aside 30 minutes for a listen.