I recently got brought on board to a new client where, true to form, a project was in a state of failure - everybody sort of knew it, but nobody would say it out loud.

What Was Going Wrong? 

After my initial assessment, I made a quick decision that the major thing holding everyone back was an early decision to use MOSS 2007 to host an external website, and as the primary content management system. This wouldn't have been a totally bad decision, if the team had a lot of good MOSS 2007 experience on board, but unfortunately they were learning as they went. If there is one thing that really doesn't work well in MOSS it is a "lets just start and change it as we learn and go along" approach. MOSS takes a fair amount of careful up front analysis and planning to get right, and has enough permeutations and "gotchas" to require some good experience on the team before starting. Otherwise you can rapidly end up with a big ball of mud.

So we took the decision that using MOSS was a major stumbling block, and this had to be removed from the equation. Of course it *could* have all been done in MOSS, but it wasn't going to happen in the time left. There was also a small "jedi mind trick" involved too ... people had become so focused on the SharePoint "way" that they could no longer see the bigger picture.

The decision was made to separate the public application away from MOSS, and to write it as a bespoke system. MOSS would still be used internally for document collaboration (which is where the strength of MOSS lies), and later on for publishing that information to the web site.

The Software Stack 

After some fast prototyping, some instinct based decisions, and a bit of faith, I finally decided on the following software stack to write the application:

• ASP.NET MVC (preview 4)
• NHibernate
• Castle ActiveRecord
• Castle Windsor
• Rhino Commons (IRepository, ARRepository, UnitOfWork)
• log4net

Some of these were fairly safe choices, I have used them before, or they are tried and tested in the field. But obviously the major exception to that rule was ASP.NET MVC

I very briefly considered Monorail, but it does not have the tooling support or documentation support of ASP.NET MVC, and going forwards Monorail is likely to dwindle whilst ASP.NET MVC will only grow.

I also considered writing a Webforms application, and using MVP to split the UI from the logic, but this approach required a fair ramp up from the developers, and had too many possible variations to try and coax people into the right appraoch.

ASP.NET MVC therefore would provide a degree of familiarity to the ASP.NET developers we have in the team, whilst providing a clean separation of responsibilities. The only question was stability, which after asking around seemed not to be an issue, despite being only at preview stage (something MS haven't done before but is very welcome here) nobody reported any problems.

By changing pretty much every element of the software stack we were using the team has been revitalised, and has approached the project with renewed vigor and enthusiasm. They get to learn some new things for their CV (pretty much none of them have used any of the new comnponents), and due to the amount of "magic" that things like Rhino and Windsor introduce they could get on with writing real functionality almost from day one.

I am very impressed by how fast the developers have picked up MVC, here a large amount of credit goes to MS for making a very usable, approachable, and simple framework that does exactly what it needs to, and very little more.

Making it Build With Continuous Integration

When I arrived there was no project in place. Nothing, nada. I could not pull the project, build it and see it work. As everything was being done in MOSS people were writing projects for each small bit of fucntionality, and manually copying assemblies into a single MOSS deployment. And the only source control that existed was Visual Source Safe. To say the least, this was scary.

So the first thing I did here was to install VisualSVN and TeamCity and get a build server running. After setting up a single solution with all the relevant projects included, we now have a build that operates on every check in, and it automatically displays on a web site for everyone internally to see the progress. On the dev machines we installed Tortoise SVN and Ankh SVN, Ankh now seems a lot more stable in version 2, but has some irritating quirks still - it is however much better than any MS source control plugin, and falling back to Tortoise almost always fixes the problem.

We also installed the trial version of ReSharper on the dev machines. None of the people here had used it before, but within only a few days we were hearing a lot of "oh wow", "that's amazing", and "that used to take me so long to do" ... in a week or two we will have to buy licences, but I think it has more than justified itself to the development team.

The URL of the build site was distributed to the business users, and now they take an active interest in telling me the "walking skeleton" is a "pile of bones" when someone changes the DB loging details last thing at night :)

Changing the Process

Also evident was that the approach that was being taken to the project was classic waterfall, along with a mixture of daily constantly changing and fluctuating requests and requirements. Communication was good with daily meetings, but the same things seemed to be repeated at each.

So another bold decision I took was to approach this as a far more Agile project - using some elements of XP.

I threw out the gant chart - much to the dismay of the project manager - and started writing up story cards, which promptly got placed on a commandeered wall. The project manager now has these story cards listed in an Excel spreadsheet so that he and the people he reports to can see exaclty where things are in a palatable form, but the wall remains the "one true master"

We changed the 8.30am sit down meeting to a 9.30am stand up meeting, and have been trying to enforce a fast "what I did yesterday, what I will do today, what is holding me up" approach to stop us getting dragged down into details.

We now have a lot more communication between developers as a result of this, and the business representatives are feeling very involved. There is still a degree of trepidation around what will be delivered, my protests of "you can see it as it goes along" and "it will be done when it will be done" are proving quite hard to swallow, but I think everyone understands there is no magic pill here and we just have to judge it step by step.

The Proof Will Be in the Pudding

So some good early steps have been taken. I cannot say the project is back on track, but everyone is now far more involved, has far more enthusiasm, and can see something starting to take shape. The perceived deadline of a few weeks from now is unlikely to be met with a fully functional site, but as "fully functional" is only vaguely defined, we are aiming to have something that is "good enough" by then, and then to make it better as people feed back into the process.

So far a major success on the approach, now to see if we can turn that into a successfully delivered solution!