Diary of a Soccer Coach: Week 2 - Inter-team Communication, Noise, and Dealing with the Unexpected

Even before I woke up the day of our first Soccer practice I found myself glued to the weather channel.   After seeing the massive thunderstorm and rainfall affecting so many College Football games during the past weekend, and knowing that the remnants of Tropical Storm Lee were predicted to stall out and take time to clear out I was growing in concern.   Some of the weather maps predicted as many as five inches or more of rain locally.   Flash Flood Watches had been issued by the National Weather Service, and there appeared a high probability of rain in the forecast for our game.

Now normally, a little rainfall would not have introduced a bit of concern about whether to have our Soccer practice or not.  Typically the only thing that has ever affected that was thunder storms, or extreme bitter wind chill conditions.  In truth only once in the three previous years I have coached has any of these conditions even been approached.   So naturally I was a little concerned here.   The place where we practice is in a low lying area, that lies in a flood plain area that has flooded in recent memory.  Because of this it was important to know what the weather conditions might be for the weeks practice.

As it happened though, by mid day the rain had mostly moved on, and though still overcast, the rain was gone, and it was modestly cooler, although humidity was still high for our practice.  In software teams, how often do we plan for contingencies like these that could disrupt development, or delay deployment?  Sometimes the unexpected may happen.  A freak ice storm could knock out power to your data center.  A Nor'easter could barrel up the coast and cause localized flooding around the facility you were supposed to test remotely against.   What if the shipment carrying a key part for your data center crashes forcing you to wait an additional two weeks for a customized component to be fabricated?

These are natural impediments that could affect your development process.  As a Tester, a network issue could deprive you of the ability to test on your virtual laboratory.  It could result in a mistaken deployment that results in a dirty configuration unlike the clean environment you are expecting and then it can cause problems as you start encountering bugs, and half to track them down.  There are perhaps a hundred or more situations that could result in what I call a noise condition within the team.  Some of them are internal, within the mind of the tester or team member, some of them are virtual, on the box or serve where testing is to occur, and some could be physical or natural noise that can interfere with your ability to test effectively.

Some of these impediments can be considered in your deployment process, and perhaps avoided or at least minimize the effect it has upon your testing.  However even the most rigorously documented process is only as good as the people implementing it.  As we are human beings, and prone to make errors, you can never avoid all of these.   A missed deployment to a test environment could indicate a whole or missed script in the deployment process.  Why did this script get missed?  The manager may ask this question, but I find the same thing can happen in the soccer field as well.

For the second week of Soccer, I like to hone in on two key skills.  The first is communication.  Whether the players realize it or not, learning to talk to their team mates on the field make a big difference in how they will play down the line.   For Soccer the simplest form of conversation is the pass.  A simple plant of the off foot toward the targeted team mate, and then following through with the passing foot, ankle locked to connect with the center of the ball right about the inside of the ball of the foot.  If done right, the ball will travel straight and follow the same line of travel that your foot was pointing.   I demonstrate this once or twice to our players, who I've saved the trouble of having to find a team mate to pass to, by pairing them up, and have them start with this basic pass.

So I watch the players as they work on their first few passes.   Some kids pick this up very quickly, some quickly get frustrated.  Younger, smaller kids may not be able to kick the ball as far or hard, or might be more focused on kicking the ball, than the technique of the inside pass.   I watch for moments like these, and let the player try a few times before stepping into correct them.  Sometimes they figure it out by trial and error, but sometimes they keep doing it the same incorrect way, and I can see it could cause a bad habit to form.

At this point as the coach, I step in.  I remind the kids to plant their foot toe pointing towards their team mate, to lock the ankle with their toe slightly raised towards their shin and connect with a straight swing of their foot connecting just above the mid point of the ball with the ball of their foot.    A couple more passes, and a little more encouragement may be required.  Keep your eye on the ball (once they get the skill down this may not be as important, but early in the drill process a it may help if the player sees as the perform the task.)  After a few more times if one or another player are having difficulty, then I may step in and demonstrate again, showing what to do, and then emphasizing the difference in how I performed the pass versus how they are doing it.  

One of the common early problems I notice is a player trying to kick the ball with the toe of their shoe.   Kids seem to think they can get more power passing this way, but it really leads to an unpredictable movement of the ball, especially for the younger inexperienced player.  This isn't something you want the kids to do early in their development.  The toe is a very small area on the foot, and many shoes are 'V' or 'U' shaped meaning that if you miss the exact center of the ball and shoe you may hit it more to the right or left and the ball will go out in the corresponding direction. I may even have to demonstrate how wrong this is, so the kids can see the difference, but after doing so I get them doing the passing correctly, back and forth, and may float between pairs, repeating this process as need be.  

As more of the players seem to get a hang of this simple pass, I will then offer them the option to try the same style of pass with their normal off foot (typically the left), and then give them a demonstration of a more advanced pass.  This time using the outside of the foot just behind the joint of the littlest toe and driving the foot to the side, you can actually pass to the side.  All the while I continue stressing, getting the team mates attention, pointing the foot in the proper direction and following through on the kick.

This may seem like a very repetitive and boring process, and for some of the older kids it might.   It doesn't take but a few minutes before I begin to see the first side effects of noise on the practice field.  There are other things to get the kids attention.  Someone brought their dog with them, a butterfly might fly onto the field drawing attention from the drill.  Kids on another field might be doing a slightly different drill and that catches the kids attention.  We have the same kinds of noise in our software teams as we communicate.

A HVAC unit could be louder than normal, a team member may be mulling over some problem they've encountered as we're describing a test we just ran, and the flaw we think it uncovered.  Whatever the noise may be, that noise can impede our ability to communicate effectively the point we are trying to make.  So how can we avoid noise?  Sometimes it may involve asking another team, that is goofing off in the cube next to you, to keep it down as their voices are starting to carry.  Maybe it involves interrupting another conversation that has your team mates attention, when what you need to say is more vital.  Sometimes we have to wait for the noise to pass, such as when a train goes by blaring its horn and drowning out almost everything else you might hear.  Assuring we can communicate our message is key in any context.

Now these example are good if it is an audible noise, what if it is an internal noise?  This is where noticing nonverbal cues is important.  If your team mate is listening, but focused on reading something on a wall, or their computer screen, it may indicate their attention or focus is elsewhere, that could be internal noise.  Another example, is if someone has a habit of doing something with their hands.  It could be something as simple as scratching the back of their hand, playing with a toy of some kind, or twirling of a pen in their fingers.  All of these are nonverbal cues that your team mate try as they might, may not be committed to the conversation.

So how can we avoid these things?  In soccer, when passing I encourage my player to start the passing conversation by calling their team mates name.   Then as the ability to pass becomes second nature I instruct them to keep their eyes ahead of them towards where they are passing the ball.    The other player, I instruct to keep their eye looking back towards the ball as often as they can while moving around the field, so they are prepared to receive and complete that transmission of the ball across the grass of the field to their feet.   Ever wonder why eye contact is often stressed in verbal communication situations?  If our eyes are turned away from the team mate who is trying to communicate with us, then also our ears may be turned away and reduce the optimal ability to hear what they are saying.   That is not to say that we should stare a hole into the head of the team mate we are trying to communicate with, but we should make enough eye contact to show that we value what they have to say.

What do you do when your comrade's attention is wandering, or they are busy multitasking and can't seem to keep up with the conversation?  Ever been in a meeting, in person or virtual were someone is being told something and then the speaker follows with what should be a typical yes response question?  "Does that make sense, John?"  The initial reaction may be for the person to say Yes, but what if their attention had drifted, they might realize they didn't fully absorb the importance of what was being translated to them, and the cue, is John's chance to say, "No, I was having trouble following what you are saying, can you please repeat that?"  During any conversation we can show our continued attention, not just by eye contact by other nonverbal and verbal cues.  Nodding of our head, a quiet yeah, or aha can indicate we are following the chain of the conversation well.


There is one more nonverbal cue I look for when talking with a team mate.  That's when their hands come up to their mouth.  You've probably seen someone at some point do this.  You mention something, and they may begin to cover their mouth with one or more fingers, indicating subconsciously that they are trying to parse together a question or response to what is said, but those fingers indicate that a lot of thinking is going on.  This is a telltale stop sign.  If you see a team mate do this, then it is highly likely that they have a different point of view, or something to contribute to the conversation.  There are other mannerisms that can indicate this desire to contribute back to a conversation.  Someone looks like they are trying to reach out and give you a subtle stop sign, is another.

There are so many things we may communicate through nonverbal cues.  How often do we ignore these cues and keep on rambling through our point, wanting to reach its conclusion without allowing our colleagues to collaborate and fully commit to the conversation?  Regardless of your place on the team, be it a tester, developer, manager, or team player.  Communication is critical.  Without it, the noise may increase, and the ball we are trying to pass to our team mate may end up in the wrong cue, or intercepted by the competition and then we are back tracking trying to recover, and catch back up to what we've lost.

So as you go back to your work spaces, consider these thoughts: Where in your environment does audible noise interfere with communication?  What can you do to work around it?  What can you do to react better to the nonverbal cues of your colleagues?  How can you make sure they are able to contribute to the conversation, and thus collaborate towards a better end?

Diary of a Soccer Coach: Week 1 - Getting the Players Attention

As I enter my fourth season as a Soccer coach, I can't help but reflect back on the previous three years.  There have been a lot of kids I've had the opportunity to work with.  The prior three years I coached the 'instructional division' as it was first called to me.  In essence I've had the honor of coaching up kids ranging from Pre-K  through Kindergarten age.   I've coached the same level for three years now, and again this year I am stepping up to do the same.

In some ways its hard to be a coach to the youngest in the league.  Some of them are already quite athletic, but lacking in coordination, some are squeamish about falling down, or running into someone else.   Some don't quite know what to expect from this their first athletic endeavor.   It isn't always easy on the coach either.  Sometimes we just barely get a season to get to know the kids before they begin to bloom and are ready to play up to the next level.  Some only get the one year, then are moved up with the other kids their age.   In essence each season is like starting over fresh.  There are always a few faces you remember from the previous years, and you may recognize the growing boys and girls practicing on a field not too far from your own teams, but your focus is now on the next group.

For companies like my current employer, where professionals might work on multiple projects, or bounce  between roles and wear different hats within or between teams as the needs become evident, to a team leader, it can seem quite a challenge to start from scratch with a team.  It can also be a challenge to get the new people involved and fully engaged and invested in the project.  

For the first session of the Soccer season as with any team, it is imperative to set the ground right.   The first practice always starts with a quick introduction and brief overview of the most basic rules of soccer.  Then we quickly transition into a couple of warm up exercises.  They aren't typically long exercises, but are designed to get the players moving, loosened up, and in the mind of being at practice.  Warm-up exercises could be great for team building, or for helping to transition a new team member into being part of the esprit de corps.    Having transitioned to several projects in my career, I feel that many of these warm up exercises did a lot to help smooth my transition into the team.

Of course, practice does not end with these warm-ups, nor should it be the end of the team building process either.  As Michael Larsen (@MKLTesthead) so eloquently put in describing the stages of team development in his emerging topics talk on teams and the EDGE method employed by the Boy Scouts of America - The team is still forming, here, it hasn't even begun to play soccer, nor has the new team or hire really progressed to a state of being fully in tune with the team's software development process.

So the next step of practice, is the first of many drills.  For soccer in the introductory division, the most basic of drills typically involves dribbling, around a pair or square of cones, emphasizing technique for controlling the motion, the tempo of the dribble.  For software teams, tempo, and pace are something that teams struggle to achieve, and hold once they have it.  The same is true for Soccer, and our instructional division is no different. The secret you see to these kids, and I'm betting many other youth organizations, is to keep the meeting or practice as active as possible.   

So we run them through a drill for five, maybe ten minutes, and then may start another.  This gets the players used to moving around, and focusing on one type of task or another.  However, at some point the kids need a break, so we give them a bit of time to run to the restroom, and get a drink before having our mid practice huddle.  More on these huddles in a later entry, but suffice it to say, the kids almost without fail come back refreshed, and ready to do more, but it is still the First practice, and i its important to temper our expectations with that in mind.  

With software teams, the same is true.  Each member needs down time to assimilate lessons learned, to rest from exertion of the mind, and for testers, to de-focus or refocus on whatever the next task may be.  Without this crucial down time, tasking begins to run right into the other so quickly that one may begin to lose sight of where one testing objective ends and the next begins.   It also presents a danger, because as creatures of habit establishing routines that are unhealthy will inadvertently result in inattention blindness, and as tempo and feel for how the project flows is learned, the risk increases that things move at a certain pace simply because they've always moved at that pace, whether the process or project are really at a achieving and sustainin velocity or not.

For my players in their first practice of the season, I see them in the scrimmage we typically run at the end of each practice.  They chase the ball without any rhyme or reason, with out any strategy or objectivity.  They believe the goal is to get the ball, and that to do that they must run to the ball.  There's just one problem.  someone else has that ball, and is accelerating in a different direction. so each player changes their angle to try and chase the dribbler down often from behind.  

At times it can look like  a swarm of honey bees, buzzing to one corner of the field, then changing course and quickly buzzing to another all around and trying to catch the ball each time, and inevitably these kids will trip, fall, or bump into another.   We haven't yet taught these kids how to move laterally, or even backwards when necessary, nor have we shown them the strategy of picking a place between where the ball might go to cut it off, rather than trying to chase it as if chained to the player with the ball like a rail car.  Inevitably the first practice always looks like this.  The older kids may not run into this scenario, as many have years of soccer under them by the time the season has started again, but for these new boots to the field of play, or to their team in the software world, they're a blank slate practically and in need of mentoring and guidance.  

The question you have to ask, is how can I influence them for the better, and help them see their role as more than just chasing the ball, as chasing this bug or that bug, when they may be leaving square feet of the field uncovered that could give them an advantage?   For me, it is important to remember that this is the beginning of a long journey we take together, and for better or worse we are here as part of a team striving to create that which our client needs.  However, even us experienced software professionals can occasionally trip over someone else's toes and fall flat if we aren't careful.  So trod carefully in those first days on a team, until you have a good picture of the terrain you must climb.

Today, I Choose Yellow

Sometimes the smallest things can be inspiration for test ideas.  Sometimes they make you sit back and pause and consider.   After enjoying a nice lunch with my family, my wife presented me with a colored page of Dora the Explorer, with my daughter's name and the date on it.  I took it to work and proudly displayed it on part of my cube wall.   I examined the picture and considered how she had gone to work coloring it.  Now she's not even two years old yet, so staying within the lines is not something I'd expect from a soon to be two year old.

However, two things jumped out at me.   For this page she had chosen a single color: Yellow.  It wasn't any particularly stark or bright shade of yellow, just a plain almost mustard color.   So then I began to think, why Yellow?  Dora isn't blonde, she has brown hair.  Her shirt is usually pink, and she wears orange pants.  Her backpack is a shade of magenta or a light lavender.  So there isn't a lot of Yellow there to work with as inspiration as far as I could tell.

So when I ponder why she selected those colors, as a Tester, the initial thought was that she had a reason for choosing that color.  I wasn't present when the picture was colored, but when I think back to the beginning, of other pictures she has colored, then the reason becomes clear.  My little one you see, isn't logical yet, her mind not quite fully developed.  She's bright and smart, charming even in her own way, but she's not even two yet.   More than likely she chose the color yellow because that was the first crayon her hands came around, and then, instead of changing colors for different parts of the picture, she continued until her mind felt she had colored as much as she dared too, and then moved onto something else.

How many of us as testers and software professionals do that?  How easily do we grab a hold of an emotion or an idea in any particular day and then view and work the entire day as if through that color whatever hue it may be?  Does that emotion and idea affect everything we do that day?  Do we let it bleed into our code, our testing, or our conversations with others?  When they look at you that morning, will they see the color yellow?

I learned from a book "Anger is a choice", that many emotions, anger in particular, are neither negative or positive.  It is how we react when those emotions come up that determines how we are viewed.   How many of us as Test or Software Professionals have encountered something, maybe it was minor at some point and we let it go, but it nagged at us.  As much as we tried to ignore, or deny this one thing, there it was the color of red, that our mind didn't want to ignore.  At some point, do we then find our focus so deeply on the color that we begin to see everything as if it was tinted that shade?

There's a danger here for Testers.  When our reaction and emotional make up begins to bleed through into our work, into our analysis and observation of systems under test, there is the possibility that it could lead us astray.  It could cause us to miss something that we'd see if our attention were not partially focused somewhere else.  It could cause us to react reflexively to something someone said that was intended in all good fun, or perhaps to help us with something with which we are grappling.

It's important I think to remember that Testers, like the clients for which we test software, are emotional beings as well.  Maybe our clients will see red when this one really annoying malformed feature crops up again and again.  Maybe they've ignored it thirty times through the application, then one day, when their emotional system is already spent from something that happened on the way to the office, or at home, and bang that one annoyance becomes the lit fuse that sets them off.  Ever know any people like that?  Ever had a client like that?

Now let's turn this on its head.  Maybe there's some issue, some flaw, that the team doesn't really classify as a fault in the software, some piece by which something is not as correct as it could be, but in your mind you, or the team in general have decided that's not important.  It's a minor, non-critical issue, and why would a user care if the time and date are displayed in YYYY:MM:DD form vs DD:MM:YYYY form?   Maybe on a normal day they won't, but do we ever consider how emotion on the part of the client, may play to what bugs they see as critical or important?

Furthermore, do we as Testers always try to enter into our testing sessions with as blank an emotional slate as possible?  Do we try to be like the Vulcan's of Star Trek utterly devoid of emotion, and creatures of pure logic for the duration of the test run?   If so, why do we do this?  Do we think a user will view the software with such a dispassionate view of how it works?

If, like me, you have ever had the chance to work the support lines for a company, then you know what I mean when I say that the customer has a personal way of dealing with his or her own emotions.  They may be struggling to get the software to perform, maybe they've had training and have used it successfully in the past, but one little nook, one little detail escapes them as they are partially distracted by some emotional atrocity they have endured this week.

Michael Bolton, no not the singer, or guy from office space, gave a keynote talk at the 2011 Conference for Association of Software Testing.  Michael talked at length about the history of testing, and at one point described how decisions on quality are "both political and emotional."  Another tester there, Michael Hunter (@humbugreality) in one of the emerging topics or lightning talks also talked about the 'emotional tester'.  I was able to follow some of these talks online, and I can't give enough kudos to the organizers of CAST and the hard working volunteers that worked to have those talks and the keynotes available online for those of us who were unable to attend.

How much role does emotion really play in our craft?  Do we allow it to simply be, to drive our assessment, to harness, or control it?  Do we inject it intentionally to see how it may color our opinion of an interface, or to see how our perception changes when our mood has changed?  Those are questions I'll probably ponder for a while.  It's funny how something as simple as a colored picture of a cartoon character by my youngest child could bring me back to contemplate these ideas in testing, but then maybe these ideas have been buzzing in my head since I first heard them, just like the color yellow.



(Edit: Thanks to Justin Hunter (@hexawise) for remembering it was Michael Hunter who gave the emerging talk on "Emotional Testing""

So what's your priority?

In the fast paced world of software development, sooner or later you or someone on your team will find a situation where they are faced with multiple tasks, and competing priorities.   So what does a person do when an urgent list of changes to a software under development is received?   Then what do you do when the expected time to deliver these features appears to be something rather aggressive?

Let's take a step back for a second to discuss the requirement process.  Often requirements are not as detailed as necessary to begin to design or codify.   Sometimes requirements may be in a list form, they may be rather obvious, but more likely they are obscure, cryptic, or down right confusing.   Because of this, very often there is a necessary feedback loop between the team and the client just trying to make sure they understand the change, and the impact it may have on the system.

This back and forth, haggling over specifics, and gaining enough understanding to model the process necessary to be implemented can be very time consuming, and often the hardest part of the software process. Customers do not always have the computer knowledge to give sufficient feedback about what they write, and as a developer it is our jobs to not just verify that we are building the software correctly, but even more critical, we must validate that which are building actually meets the needs expressed in the requirements.

Often the understanding of a requirement will morph over time, but for simplicity's sake let's assume for a moment that the haggling over the requirements has already taken place.  So your team is called into a rushed meeting to discuss a list of changes.  The manager describes the ten items that need to be implemented, and expresses the hope that it can be done in a short amount of time.  For sake of argument lets say its a week.

Immediately the issue of time and priority may come to the forefront.  If there are ten changes to a system, ten changes that do not necessarily 'interact' with another or depend on another, then how do you prioritize them?  Depending upon what model your process is based upon the answer could vary.  It may be the Project Manager who sets these priorities, or in a more agile environment it could be the customer, or the person designated as the 'product owner' within the team.

So the team after a little debate comes to the decision, much as they might like to pick and choose which pieces to do in what order, they need one more layer of feedback about the requirements, what is the order of priority for these changes.  Given that the team is taking some measure of risk trying to rush these ten features into the system in a week's time, they believe that this risk would be easier to stomach if they could impose some logical order to implement the features, so that if the time should prove insufficient, they could at least be sure to have the  most critical features done and deployed.

So what do you think the response would be?  Hopefully you'll get a list of points itemized from one to ten giving a clear order of development and importance to the customer.  That would be the ideal, but what if the list comes back with six of the ten items listed as priority number one, and the other four as priority number two?  I posed this question on Twitter.

I received a few different responses two of the more interesting ones were from Stephan (@S_2K) "Everything is most important. " Morgan Ahlström (@Morgsterious)  replied with the understanding words "That noting is REALLY important."  These were very much my same sentiments when I pondered this question.  If someone cannot distinguish a hierarchy between two things, let alone ten things, how then can you know which items are of most importance and tackle those ares of the software first?  Even if you have multiple team members, it is only natural that some components may still have higher precedence.  


So what do you do when you have this sort of situation?  My hope would be that enough time would exist to push back for further definition of the structure of the requirements.  However, given that the customer might not be as eager to be asked the question a second time, or might not be as readily available, the team is then left to its own deductive skills to try and figure out the proper order to do them in.   This is where knowing a bit about potential dependencies within the requirements could lend aid into determining an order of construction. 


Nevertheless, it is still highly probable that there can be no clear prioritization gleamed from this answer.  With time being ever more tight then the team is left to its wits, and knowledge of prior conversations to try and 'best guess' the order they should tackle the changes.   In the end the team might complete all ten, or they might completely only a handful of the tasks.   In the later situation, the customer might then push back and ask why they completed one task but not another.  The team then can remember that it didn't get the accurate feedback it requested on prioritization, and could provide this as reasoning for the order they had chosen.


The customer might not like that sort of response, but sincerely in the absence of information, it becomes better to complete at least some of the work, even if you do not know how much, or what order it should be done in. This may not be an ideal solution, but it should be evident from this how important communication with the customer must be to ensure accurate building of the software and the timeliness and sequence of delivery.

Some thoughts about Version Control

In my time as a software professional I have seen many systems for maintaining and tracking changes to code in progress.  Whether this is the archaic and I hope no one ever really uses this on a real project practice of passing along zip files of changed code with comment mark-up to indicate where changes were made, or to full featured source control solutions, like subversion, team foundation server, or git, every project at some point or another will have to make a decision on how to handle these files.

I could spend time dealing with the importance of choosing any source control solution, but that's not what this post is about.  Instead I'd like to take a moment to describe some of my experience with source control solutions.

In general there are two sorts of source control mechanisms, one is like that used with Microsoft's Team Foundation system (and before it Visual Source safe an incremental check out/check in system, and the other is a check out the code base, and commit/update to get/add the latest changes to the current working version.    There are pluses and minuses to both schemes.  The incremental check out/check in system really feels like a pull system.  While you can download the latest tree from a base directory, to make changes, and have them be saved with out the IDE screaming about read only or protected files, you have to make a point to check out in essence pulling on TFS to make the file ready for editing.   Team Foundation Server (TFS) allows you to do this in an exclusive mode, essentially locking out any other attempts to check out and change the file by other users, or a less prohibitive more shared lock.  

I've only had the privilege of working on a single project with TFS thus far, and that project relies on the exclusive kind of check out system most of the time.   This means that if a developer needs to make a small change to a file that you are working on, he will have to communicate that need to you, so that you can then do a hand shake of releasing the locked edit, so that the change can be checked in.  It can be a real pain at times when you want to try a quick fix and the IDE prevents you at times from trying something simply because it's marked as 'read-only'.  It provides a benefit in that it limits the number of files you might accidentally touch which can be a blessing at times.  It also means that anyone trying to check in another fix may not be able to do so while it is held checked out, and as has happened to me a few times, sometimes files in a project may get checked out by the IDE automatically even if you did not intend it so.

The other form of version control management is the style for which Subversion has become known. It is in essence a more push style of architecture, where by, you can check out an entire source control tree (much like getting latest for any particular folder), and then have significant freedom to make changes, erase a file and refresh/revert it from the last commit, or even make a series of changes and check them in one after another.  The draw back of this system, is that because anyone can edit, there is the possibility of files getting more and more out of sync from the base or trunk as it is called in subversion.  This can present problems when during a commit a major conflict arises trying to reconcile differences between the two files.    In my experience though, if used judiciously and kept up to date and committed as often as necessary, these conflicts can be minimized fairly easily.   Subversion also has the bonus in that it is portable to other operating system types, and is not dependent on the windows/.Net stack as much to function.

There may be other tools that fit your needs better, Wiki's can be edited inline from a browser and keep good version tracking of each meta page, content management systems like Share Point can allow you to track updates to your requirements, contacts, or serve as a portal for storing key documentation for a production.  Whichever tool your team chooses for source control, it is critical that your entire team is on board with its function, and regular use to help avoid major headaches between builds.   The value of source control is manifest in how it allows teams to track branches of in progress development code, tag certain releases for easy comparison later, and giving a history with comments about the update and logs of the files that have changed.  This logging function can be of great value when trying to track down how a particular strain of bad code may have made its way into your product.

Then some source control systems allow you to track the progress of development from requirement, to deployment.  Team Foundation Server has these features out of the box, while open source tools like Subversion require other components, for example TRAC, to help track the progress of development.  I hope that whatever your team chooses to use, that you will find the source control to be a great asset, that helps facilitate your development needs.