I've often heard and seen large teams struggle when implementing some agile project practices in large enterprises. I recently joined Corbis who were using many agile practices (introduced by my boss, David Anderson who wrote Agile Management book), but Continuous Integration and Automated Builds weren't on the list.

We discussed why CI was needed for a while, and then successfully implemented it. During this process, I kept careful notes on the barriers we encountered and how those barriers were overcome. On David's urging (I mentioned he was by boss right and does my reviews), I put together this draft article (Continuous Integration at Enterprise Scale.pdf (681.47 kb)). I'm keen to hear feeback on it.

Here is the Introduction -

Introduction

Continuous Integration and an Automated Build process are common practices employed by many high-functioning agile software teams. Many small teams are reporting high productivity improvements, but success stories of Continuous Integration and Automated Builds for Enterprise Scale software projects are much rarer. Some agile pundits have stated that there is a scale limitation for agile practices and these practices are in-appropriate for Enterprise Scale (or high staff count) projects.

This article aims to explore if and why the measurable benefits of Continuous Integration and Automated Build processes begin to decline as application size, and team size grows.

Our conclusion is that there is no inherent reason why Continuous Integration and Automate Build processes won’t scale to any size team. In fact, this article concludes that the problems these techniques solve are a higher pain point for Enterprise Scale applications and become more essential than ever. In addition, this article provides guidance on how to scale agile practices and how to make smart architectural choices up-front to ensure smooth adoption of Continuous Integration and Automated Builds leading to smoother projects and improved success rates.

Interested in your thoughts....

Troy.

Continuous Integration at Enterprise Scale.pdf (681.47 kb)

This came up today in the office, so I thought i'd post a reminder of a useful operator in C# that first appeared in C# 2.0.

When Nullable Types were introduced, Microsoft also added an operator to make dealing with null values easier. This avoids a lot of if/else checking for null values.

The normal form is:  [variable] ?? [value if variable is null]

A simple example is when dealing with nullable types, like nullable int values -

int? i = null;
int? j = 42;

int result1 = i ?? 0; // result1 is 0
int result2 = j ?? 0; // result2 is 42

The results are: result1 = 0 (because i was null), and result2 = 42 (because j had a value).

The null coalescing operator removes a lot of the clutter of testing a variable for null and assigning a default value. This is often necessary when casting a nullable type back to its non-nullable counterpart.

To read more see lots of references on this Google  search.

Troy.

This came up today in the office, so I thought i'd post a reminder of a useful operator in C# that first appeared in C# 2.0.

When Nullable Types were introduced, Microsoft also added an operator to make dealing with null values easier. This avoids a lot of if/else checking for null values.

The normal form is:  [variable] ?? [value if variable is null]

A simple example is when dealing with nullable types, like nullable int values -

The results are: result1 = 0 (because i was null), and result2 = 42 (because j had a value).

The null coalescing operator removes a lot of the clutter of testing a variable for null and assigning a default value. This is often necessary when casting a nullable type back to its non-nullable counterpart.

To read more see lots of references on this Google  search.

Troy.