Here is phase 1 of the script:

# Phase 1: add all local files into TFS which aren't under source control yet
$items = Get-ChildItem -Recurse 

foreach($item in $items) {
	$localItem = $item.FullName
	$serverItem = Get-TfsChildItem -Item "$localItem"
	
	if (!$serverItem -and !($pendingAdds -contains $localItem)) {
		# if there's no server item AND there's no a pending Add
		write "No such item as '$localItem' on the server, adding"
		Add-TfsPendingChange -Add "$localItem"
	}
}

With over 10,000 files in the local directory, calling Get-TfsChildItem for each item wasn’t time efficient. Running phase 1 took approximately 3 minutes.

Looking at the help page for Get-TfsChildItem, we may pass an array QualifiedItemSpec[] instead of a single item. Instead of calling Get-TfsChildItem thousands of time, we can call it just once.

# Phase 1: add all local files into TFS which aren't under source control yet
$items = Get-ChildItem -Recurse | % { $_.FullName }

$serverItems = Get-TfsChildItem -Item $items

foreach($serverItem in $serverItems){
   if (!$serverItem -and !($pendingAdds -contains $localItem)) {
      write "No such item as '$localItem' on the server"
   }
}

Running the updated script still took approximately 2 minutes. It isn’t much of an improvement, but it is better nonetheless. Phase 2 of the script has the same problem.

# Phase 2: delete all subfolder/files in TFS if there's no local subfolder/file for them anymore, and check out other items
$items = Get-TfsChildItem -Recurse

foreach($item in $items) {
   $serverItem = $item.ServerItem
   $localItem = Get-TfsItemProperty -Item $serverItem 
   
   # Do other stuff...
}

For the entire collection of files found in TFS, the script will iterate through and call Get-TfsItemProperty for each file. Running phase 2 took approximately 6 minutes. Again, we can update the script to call Get-TfsItemProperty once by passing it an array.

# Phase 2: delete all subfolder/files in TFS if there's no local subfolder/file for them anymore, and check out other items
$items = Get-TfsChildItem -Recurse
$itemProperties = Get-TfsItemProperty -Item $items

foreach($item in $itemProperties) {
   $serverItem = $item.SourceServerItem
   $localItem = $item.LocalItem
   
   # Do other stuff...
}

Running the updated script still took approximately 3 minutes. Better, but still slow. After reading the help page for each cmdlet more carefully, I finally noticed that most of these cmdlets offer the -Recurse switch. Instead of iterating through each of the files in the local workspace and server, we can use the top directory along with the -Recurse switch.

$localItems = Get-ChildItem -Recurse | % { $_.FullName }
$serverItemProperties = Get-TfsItemProperty -Item . -Recurse
$serverItems = $serverItemProperties | % { $_.LocalItem }

# Phase 1: add all local files into TFS which aren't under source control yet
foreach ($item in $localItems) {
   if (!($serverItems -contains $item) -and !($pendingAdds -contains $item)) {
      write "No such item as '$localItem' on the server, adding"
      Add-TfsPendingChange -Add "$item"
   }  
}

# Phase 2: delete all subfolder/files in TFS if there's no local subfolder/file for them anymore, and check out
foreach($item in $serverItemProperties) {  
	$serverItem = $item.SourceServerItem
	$localItem = $item.LocalItem
	
	# Do other stuff...
}

The entire script runs in just 16 seconds instead of the original 10 minutes.

The two presenters are highly entertaining to watch. Although the title may be a little sensational, I still think the video promotes important messages. I’m sure a lot of people recognize the topics they discuss, but it’s still good to hear someone else talk about it openly. There are numerous topics in this video that resonate with me.

This is a 10 minute video about what motivates people. It’s an interesting video to watch, but I would take it with a grain of salt. There’s actually an entire book about this. The examples they use may or may not correlate to what happens in an actual work environment. While it may work for a subset of people, this certainly isn’t something that would work for everyone. However, I do agree with the three factors they discuss that lead to better performance and personal satisfaction:

• Autonomy
• Mastery
• Purpose

This last video is John Carmack’s keynote at QuakeCon 2011. John Carmack is a brilliant programmer and is an inspiration to me. Just listening to him talk motivates me to go try and build something great.

• Empower your team and don’t micromanage.
• Communicate well and listen to your team.
• Encourage professional development.
• etc…

However, I consider two things of utmost importance above all else:

• Honor your commitments (trust)
• Fair process

If a manager promises my team something, then backtracks without discussing it with us, I will forever look at that manager differently. There is nothing that will demotivate me faster than working for someone I can’t trust.

To quote the fair process page:

• Engagement. Involve individuals in the decisions that involve them. Get their input, allow them to actively PeerReview the ideas on the table. Respect individuals for their ideas.
• Explanation. Everyone involved and affected must understand the reason why the decisions were made. Demonstrating the rationale behind decisions shows people that you have considered their opinions thoughtfully and impartially. Not only will this make people trust the decision maker but it will help them learn.
• Expectation clarity. Once a decision is made, clearly specify the expectations for the people involved, what responsibilities they have. Even if the expectations are demanding, people want to know by what standards they will be judged and what penalties there will be for failure. Understanding what to do reduces useless political maneuvering and it allows people to focus on the task at hand.

Fair process goes hand in hand with trust. If decisions are being made without input from my team, I feel completely disengaged with the task in hand. If my manager cannot trust me enough to value my input, why should I go above and beyond for them?

For the managers I’ve worked with that employed fair process, it was an absolute pleasure working with them. I was committed and motivated to get the task done because I felt like I had a stake in the result.

A lot of the traits that I value can be found in the book Peopleware. Just like how the agile manifesto states, software development is more than just processes. If you value processes over people, you’re probably a bad manager.

Currently every user story that is created must be grouped under a feature. All features must be grouped under an epic. By the way I’ve described things so far, it appears there is a hierarchical structure that must always exist: Epic -> Feature -> User story.

To be honest, I hate this. I don’t like it at all. If a user story is small enough to implement on its own, why do I need to bother creating a feature or epic? This screams process over pragmatism. If we’re forced to always create features and epics, they are no longer features that describe how a system works. Instead, we’re using them as categories or buckets of work.

After reading multiple articles around the web, I found this article by Mike Cohn that contains a very simple and concise definition for each.

To me, a user story is a requirement that can stand on its own. It doesn’t need to be grouped under a feature or epic. If a user story is too large but not large enough to be considered an epic, it may be broken down into “tasks” that will eventually be absorbed back into the user story after completion. Many people have the opinion that a user story should be sliced into multiple smaller stories instead of tasks. I disagree because that story will be sliced to the point where it doesn’t provide any business value on its own. Instead, they become system or technical stories. A user story should be something that delivers business value on its own.

If a user story may be broken down into multiple smaller stories that can provide business value on its own, then it may be considered an epic. I really like the way Mike Cohn described themes, or what we would consider features. They are simply a “rubber band” around a collection related of user stories. There isn’t a hierarchy between a feature and epic. Since a feature is simply a collection of related stories, there are times when a feature may be larger than an epic or vice versa.

Neither epics nor features are required. If a requirement is small enough to fit inside a single user story, then that is all there needs to be.

Again, I’m not an agile expert, so this is just my opinion and interpretation.

If I am a salaried employee working 40 hours a week, the idea of forcing me to record how many hours I spend on bugs, new features, meetings, etc… is completely absurd.

Hours spent on a task is a poor metric in these cases. The idea behind logging how much time is spent on bugs or new features is that goals can be created around how much time is spent on bugs. For example, we want to spend 5% less time on bugs next quarter.

Unfortunately, that’s a poor way of motivating people. Developer “A” is responsible for 10 bugs and each takes 5 minutes to fix. Developer “B” is responsible for a single bug that takes 3 days to debug and resolve because it’s a rare race condition. Why should developer “B” be penalized in this case when clearly developer “A” needs to work on improving his code? Metrics should be formed around the number of bugs introduced and the complexity of each bug. Our goals should be to reduce the number of trivial bugs that make it into production, rather than reducing the amount of time spent on fixing bugs.

Creating goals around how much time is spent on bugs per sprint creates deceit. People will be more focused on adding new features to their sprint rather than prioritizing the bugs in order to show management that they spent more time on features than bugs that sprint. This will create software full of bugs. Yes you’ll have plenty of new features, but buggy software is still buggy software.

There are times when we need to find out how much money it took to create a feature. Since these features are estimated in story points, I don’t see why it’s so difficult to write a query in your project management software to find out it took 2 developers and half the sprint to create this feature. Same concept can be applied to any bugs that were fixed or maintenance work.

These are all estimates anyway. If you think forcing people to log how many hours they worked on a feature will yield more accurate results, you’re in for a rude awakening. People will forget how much time they spent on a feature and most people people already estimate the approximate time they spent on a work item anyways. You’ll get more accurate results by querying your project management software.

I also hear the argument that logging hours will help us identity when people are attending too many meetings, responding to too many emails, or other administrative work. That may work for code monkeys that do nothing but follow orders, but now you’re burdening other people. This relates to my previous post about discipline over forced processes. If someone feels they are attending too many meetings and cannot get enough work done, then that person needs to take responsibility and stop attending useless meetings. As long as I’m producing results on time, why should anyone care how many meetings I attend? Getting the job done is why I get paid. If someone isn’t producing value, then it should be the supervisors job to take notice and step in. It doesn’t take a rocket scientist to identify people who can’t carry their weight.

The bottom line is that management needs to trust the people working for them and treat adults like adults.

It really irritates me when I see agile zealots blindly following their step-by-step checklist. For example, some people have forgotten who our customers are. As a developer, my customer is the business. A typical agile zealot will value processes over business value. If it goes against their prescribed set of agile processes, the business must be wrong and we have set them straight right? Absolutely ridiculous.

“But that’s not Scrum”. Well guess what? I don’t care because no process is perfect. The process is not more important than the customer’s satisfaction. These agile zealots always claim to care about people and results more than processes, but they will interject if you don’t follow their checklist to the letter.

Great teams should always have the power to decide how they work, because ultimately they will be responsible for the outcome. Mistakes will be made, but it’s part of the learning process. At the same time, I’m not saying that once a process has been decided upon that it needs to be written in stone. A disciplined team will fine tune their workflow as the project progresses.

I’ve mentioned a few times that I’m a fan of the ideas behind the Agile Manifesto. However, I’m not a fan of the Agile (capital “A”) methodology/process/bullshit that is forced on me. Here is Wikipedia’s definition of Scrum:

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development.

The problem is “managing projects”. This is what happens when people becomes overzealous about a process. All I see is a narrow-minded, fixed set of steps that inhibits rationality. Scrum is designed for mediocre developers who can’t think for themselves. There, I said it.

People tell you that if you don’t follow this approach, you’re doing it wrong. If your project succeeds, then it’s because you did “Agile”. If you fail, then you were doing “Agile” wrong. This mindset breeds mediocre teams. Their goal is to teach everyone what a scrum is, what a sprint is, what are user stories, what the product owner is responsible for, etc…. The problem is that they know how to do “Agile” (noun), but they don’t know how to be agile (adjective).

When people tell me that I can’t clarify requirements with the business because the business analyst will do that for me in a separate meeting, I can’t help but think whether they’ve actually read the manifesto or not. This tells me that they’ve adopted the garden variety pseudo “Agile” bullshit and have simply cherry picked what looks good on paper.

The fourth principle of the manifesto states that “business people and developers must work together daily throughout the project”. But in a dysfunctional Scrum world, this just means that the development team sits in the same meeting with the business without contributing. I was even scolded last week when I attempted to clarify requirements during a meeting. If I hear “we shouldn’t care how the business prioritizes tasks” one more time, my blood pressure will go through the roof.

Some people may not care, but I certainly do care about why a task is prioritized in a certain order and the business history behind such a decision. Domain experts and developers do not have to be separate roles, yet this mindset of “we don’t care” completely misses the point of the fourth principle from the manifesto. People are too focused on what the software should do instead of what business goal we are solving. They are tasked with delivering a set of stories and measured on that, so they won’t see any benefit in coming up with alternative or better solutions.

The manifesto for half-arsed agile software development is amazingly accurate:

Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact.

Scrum is nothing more than just a bunch of rigid processes. Being agile is supposed to be about flexibility and the ability to react. It’s not supposed to be about rigid processes and managers who are blindly devoted to their metrics.

“Agile slave” is an accurate description. I am told all that time that if a story isn’t completely defined, then throw it back to the business and it doesn’t make it into the current sprint. This tells me two things: the team doesn’t trust the business partners and you’re blindly following a process without thinking about the long term benefits. There is still this mentality of “us” vs “them” when it comes to IT and business. Yes, you’re protecting your team and velocity in the short term, but why should I put so much emphasis on velocity? It’s just a number, an estimate.

Rather then working with the business partners to build that knowledge and educate people, you’re throwing items over the fence and moving on. People are missing the big picture. As time goes on, a relationship is formed and both sides work in unison. I don’t have to constantly question the business and vice versa because there is trust. If you’re not working towards this goal, then you’re not trying.

More and more shops now think of themselves as Agile. They’re investing in Agile training and attempting to adopt Agile methods such as Scrum and Kanban. But they’ve missed the point. Instead of becoming enlightened freethinkers, they’ve drunk the Kool-Aid and joined the Cult of Agile. Dogma and orthodoxy are alive and well. At the cutting edge of our profession are the people Andy Hunt calls “Agile slaves.”

If you are interested in distributed systems, I highly recommend attending this course if you ever get the opportunity.

string plural = Inflector.Pluralize("planet");
Console.WriteLine (plural);

Since .NET 4.0, Microsoft has added their own PluralizationService class to pluralize words. Microsoft’s PluralizationService class is actually used in the Entity Framework tools to generate singular or plural entity names.

var service = PluralizationService
	.CreateService(CultureInfo.GetCultureInfo("en-us"));

string plural = service.Pluralize("planet");
Console.WriteLine(plural);

There are cases when both classes do not generate the same plural form of a word. For example, attempting to pluralize the word “virus” generates different results. Inflector will return “viri” while the PluralizationService will return “virus”. Neither generated the more common “viruses”.

public interface IPerson
{
    string Name { get; set; }
    int Age { get; set; }
    long Birthday { get; set; }
}

If we attempt to map a DateTime to the property Birthday, an InvalidCastException will be thrown when we access the Birthday property.

var dictionary = new Dictionary<string, object>
{ 
    { "Name", "John Doe" },
    { "Age", 30 },
    { "Birthday", DateTime.Now },
};

IPerson person = new DictionaryAdapterFactory()
	.GetAdapter<IPerson>(dictionary);

Console.WriteLine(person.Birthday);

Fortunately, the DictionaryAdapter allows us to use attributes to define how properties should be mapped by creating a class that inherits from System.ComponentModel.TypeConverter.

public class DateTimeToTicks : TypeConverter
{
	public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType)
	{
		if (sourceType == typeof(DateTime))
			return true;
		
		return base.CanConvertFrom(context, sourceType);
	}

	public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
	{
		return ((DateTime)value).Ticks;
	}
}

We can decorate the Birthday property with the TypeConverter attribute and specify that we want to use our new type converter.

[TypeConverter(typeof(DateTimeToTicks))]
long Birthday { get; set; }

The previous example is a bit contrived. However, I have run into issues when trying to use the DictionaryAdapter with a result set from a database that contains NULLs. Here we’ve updated the IPerson interface with a Nullable<int>.

public interface  IPerson
{
    string Name { get; set; }
    int? Age { get; set; }
}

The following code will throw an InvalidCastException on line 17 after mapping the results from a SQL query:

using (var conn = new SqlConnection(connStr))
using (var cmd = new SqlCommand("select 'John Doe' as [Name], NULL as [Age]", conn))
{
    conn.Open();

    using (SqlDataReader dr = cmd.ExecuteReader())
    {
        while (dr.Read())
        {
            var dictionary = Enumerable
                .Range(0, dr.FieldCount)
                .ToDictionary(dr.GetName, dr.GetValue);

            IPerson person = new DictionaryAdapterFactory()
                .GetAdapter<IPerson>(dictionary);

            Console.WriteLine(person.Age);
        }
    }
}    

We can create another TypeConverter to check for DBNull and returns null if found.

public class DBNullable : TypeConverter
{
    public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType)
    {
        if (sourceType == DBNull.Value.GetType())
            return true;

        return base.CanConvertFrom(context, sourceType);
    }

    public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
    {
        if (DBNull.Value.Equals(value))
            return null;

        return base.ConvertFrom(context, culture, value);
    }
}

Again, we can decorate the Age property with our new type converter.

[TypeConverter(typeof(DBNullable))]
int? Age { get; set; }