Prompted by a discussion on the altdotnet yahoo group ... why I like broken builds ...

Some people try desperately to avoid breaking the build, by doing very infrequenet check ins (the number of broken builds per day drops dramatically, the time to fix each goes up though), or by trying to ensure their development environment is as close to the build environment as possible.

But a broken build is not a problem - it is an opportunity. A broken build allows you to identify a weakness, and to resolve it early.

The weakness might be in your architecture, it may be in your dependencies, or in your assumptions, or in your developer skill levels - but the whole point of having a continuous integration server is to fail fast and let you deal with the underlying problems rather than the specifics of the code you checked in.

I've done it before, but my mind went totally blank yesterday ... due to some typically quick responses from the Castle Users Google Group ... here is the code to do it for future generations to avoid my same silly mistakes ...

WindsorContainer container = new WindsorContainer(); 
Type eventBrokerServiceType = typeof(IEventBroker<>); 
Type brokerType = typeof(EventBroker<>); 
container.AddComponent("key", eventBrokerServiceType, brokerType); 

IEventBroker<EventArgs> eventBroker = container.Resolve<IEventBroker<EventArgs>>(); 
Assert.IsNotNull(eventBroker); 

Early in the new year my current client has asked me to present to the senior management on two areas they feel they can currently improve in, their RUP project management process, and their development processes overall.

Attached are two presentations in their early form, in PowerPoint 2003 format.

Missing from the presentations are the notes (which I will add once I am happy with the overall structure) but you should be able to figure out what I am intending to say for each slide/bullet point.

Both of these presentations will evolve over the next few weeks. Feel free to comment either by the comment option or directly to me, and if you think they will be helpful to you for a presentation, also feel free to use them and modify them as you see fit.

Agile.ppt (80.5 KB)

This is intended to give a very high level view of Agile, to a group of senior managers who practice almost none of these things at present, and who are not 'tech savy'. This is fundamentally a 'get to know you' kind of presentation, to encourage aspects of Agile to be adopted, rather than any specific methodology or practice.

Development.ppt (80.5 KB)

This is intended to be presented to a similar level group, but the audience members may overlap to some degree with the previous presentation, and some may not. At the moment it is more likely that these people are closer to the ground and more 'tech focused'.

It is intended to give some key practices that can help improve the development processes the client currently has, again without forcing a wholesale shift to a specific Agile methodology on to them.

Oh, and Merry Xmas (or whichever thing you celebrate at this time of year!)