Alex Hoffman

Perspective on development, management and technology




    IASA Member

January 2006 - Posts

Agile Methodologies on Large Projects

There has been some discussion recently on the Australian "dotnet" Mailing List about the applicability of XP and agile development to large scale projects.

Nick Randolf questioned someone's comment that "most of the practices won't work in large, dispersed projects".  He asked for good reasons why they would not?

I wrote in response ...


I like Barry Boehm's critical agility discriminators:-

Size : Criticality : Dynamism : Personnel : Culture

Size: Well-matched to small products and teams.  Reliance on tacit knowledge limits scalability.

Criticality: Untested on safety-critical products.  Potential difficulties with simple design and lack of documentation.

Dynamism: Simple design and continuous refactoring are excellent for highly dynamic environments, but a source of potentially expensive rework for highly stable environments.

Personnel: Requires continuous presence of a critical mass of scarce Cockburn Level 2 or 3 experts.  Risky to use non-agile Level 1B people.

Culture: Thrives in a culture where people feel comfortable and empowered by having many degrees of freedom - thriving on chaos.


It's now widely accepted that XP practices "must be adapted as necessary for projects that do not fit the "small team" limits recommended by its founders." (

Here in Australia, efforts to implement XP as a corporate methodology or in large projects - tend to go the way of Citect (  A "guru" will preach "values" over "process", which rapidly go out the window as processes that manage risk and offer predictability to customers and stakeholders are re-introduced.

I think that's why there is movement away from XP in projects unsuited to it's sweet spot, to say SCRUM, or one of the large team variants of Crystal.

Posted Tuesday, January 31, 2006 1:36 PM by Alex Hoffman | 1 comment(s)

Upgrading 1.x Projects and Friend Assemblies

I'm finding that one new change required on upgrading a project from .NET 1.x  to 2.0 occurs when wanting to make an assembly's internals accessible to another assembly i.e. creating a friend assembly.

In .Net 1.x, one might have default project assembly attributes as follows:-

  1 [assembly: AssemblyDelaySign(false)]
  2 [assembly: AssemblyKeyFile("")]

However, if you add the InternalsVisibleAttributeTo attribute ...

  1 [assembly: InternalsVisibleTo("AxScriptTest")]

... you'll get a compilation error:-

Friend assembly reference 'AxScriptTest' is invalid.
Strong-name signed assemblies must specify a
public key in their InternalsVisibleTo

It seems that the existence of these attributes is enough to make VS2005 think that the assembly is strongly named.  To solve this, simply remove the AssemblyDelaySign and AssemblyKeyFile attributes, or do something like the following:-

  1 #if !DEBUG
  2 	[assembly: AssemblyKeyFile(@"D:\Alintex\Alintex.snk")]
  3 #else
  4 	[assembly: InternalsVisibleTo("AxScriptTest")]
  5 #endif

Posted Friday, January 27, 2006 12:48 PM by Alex Hoffman | 1 comment(s)

Filed under:

Publishing Your Schedule From Outlook

I’m currently managing a team that uses Lotus Notes.  Because I need to use Outlook through my company’s mail server, making my schedule public – so that team members using Notes can see my schedule and schedule meetings with me – was problematic until I realised that I can have Outlook publish my schedule in standard vCalendar format.

In Outlook:-

  • Display the Free/Busy Options Dialog (Tools>Options>Calendar Options>Free Busy Options).
  • Select the Publish at my location checkbox and enter a local, network or FTP address as per the Outlook help file. e.g.

Posted Thursday, January 26, 2006 9:01 PM by Alex Hoffman | with no comments

Filed under:

More Posts