I just got back from the WAM charity event that i mentioned in an earlier post.  I want to again thank everyone on my team for all their hard work.  It was also amazing to see what the other teams had built in such a short timeframe, sometimes with only one or two developers.  I learned a lot about development and project management this weekend, so I thought I would share my thoughts.

This weekend was a whirlwind of coding, coordination, sweat and tears.  Our team consisted of 5 developers working on a small project which had around 8 tables (not including the aspnet membership tables) and 20+ pages.  The project was not your run of the mill standard website that could be built using a CMS.  Although small, there were significant complexities: each user role had to see specific things, there were complex relationships to consider between different objects and their underlying tables, there were overlaps between different sections of the application that needed some code reuse in the form of controls, and so on.

But more complex was the team dynamic.  Tina and I had worked together, Matt, Nolan, Tuan and I had not.  Also, we were constantly reminded of the "Mythical Man Month."  We kept joking that since we had 5 developers on such a small project, we should go a lot slower.  This was not far from the truth.  It took considerable effort not to step on each others toes.  Below are some of the things that I took away from the experience.

Designate a Clear Leader

Although I had the initial idea to form our group and had invited Tina and Matt to come to the event, there was no rule saying that I was the project manager or lead developer.  Also, I think I was hesitant to take on this role for several reasons.  First, I had created a visual studio solution ahead of time with the telerik controls and wilson orm already setup, because Tina and Matt and I had already decided upon this.  However, I didn't necessarily want to dictate more technology decisions to Tuan and Nolan than what we already had.  Also, both Nolan and Matt had just as many years of experience (or more) on their belt that I had.  This lack of a clear leader in the group made it difficult to make decisions at times, especially the first day when we were designing the application by drawing screens.  We had to come to consensus or vote on a lot of decisions which caused us to move slower.  Often, people did not want to take sides when there was a disagreement, so it was hard to even get a vote.  I think that either we should have voted on a leader from the very beginning, or WAM should have assigned a group leader to each project.  This doesn't mean that there can't be discussion or that you need a dictator in charge, but i think having a clear leader would have avoided a lot of the group's "Analysis Paralysis."

If Time's an Issue, Use Familiar Tools

Every developer has their own way of doing things.  One of the problems of software development is that the same problem can be solved different ways.  I think this force definitely gave us some hurdles to jump during the event.  For example, as I mentioned Tina, Matt and I were all familiar with O/R Mappers and the Wilson ORM we had decided to use.  Nolan and Tuan were not.  This wasn't TOO bad because we had three people that could help the other two.  

Early on, we had decided we all wanted to write the code in a somewhat consistent way.  Matt had suggested that we use GridView and FormView on the same page to create our screens.  So when the user clicked on a record in the gridview, the page would postback, the formview would databind and and gridview would be hidden.  Matt had used this technique successfully on a lot of applications.  So we all copied Matt's initial screens so we could tailor them to each of or pieces of the application.  I think we were all eager to learn something new.  In retrospect I think this was a mistake.  Matt was the only one familiar with this way of writing the UI.  So he ended up having to stay very late when Tuan and Nolan's screens had problems because he was the only one who understood the process.  I had a lot of issues myself but finally gave up on FormView and just used a panel to show and hide the form.  Matt may still disagree with me but i think formview and detailview do not add a lot of value unless you can take advantage of two way databinding or autogenerating the fields on the form.  Unfortunately, this is hard to do with the Wilson business objects and the ActiveRecord pattern we were using.  My experience has been that FormView, DetailView and Datasource controls really require you to do things the microsoft way using datasets or a very specific structure to your business objects, in order use them effectively.  I noticed a lot of us had duplication in our code and struggled with the myriad of events raised from the GridView and DetailsView on the same page.  Towards the end, I think most of us reverted to using the method that was most familiar to use, which probably made the codebase less consistent.

In addition, I was the only one who understood subversion.   I think this was a problem as well.  I became a bottleneck whenever a conflict arose, which was often due to the small number of screens in the application.  The project file was especially problematic as all of us were constantly adding new files.  In retrospect, I think we should have used the "Lock..." feature in subversion and tortoise so that we could simulate VSS's exclusive checkouts.  Unfortunately, I didn't think of this until the tail end of the event.  There was lot of stepping on each other and versioning conflicts because of the number of developers in such a "small space".   I think the lesson learned here was that "exclusive checkout" is actually more productive than "multiple checkout" when you're on a small project with that many developers in that short of a time span.

Three of us were using TortoiseSVN but Tuan and Matt were using RapidSVN.  I had suggested before the event that we could use any client with Subversion, but I had very minimal experience using RapidSVN.  So it might have been easier had we all been on the same Subversion client as well.  

Finally, even the Telerik controls were an issue.  We used the RadEditor to allow the users to enter Html content.  I got the RadEditor working but then I wanted to use the same image browser/uploader in the editor in a photo album part of the site.  I was able to get some javascript working to launch the image browser without showing the RadEditor, but then getting the name of the file back to the page took a long time to figure out.  Matt, Nolan and I spent hours on this alone.  

When You're Going the Wrong Way, Turn Around

Several times during the event, I noticed that one or more of us would get stuck on something.  Because of the short time frame, we were often afraid to give up and start over with another tool or technique.  The fear is that if you have already spent 2-4 hours on something, you don't want to give up when you feel so close to finding the answer.  The running joke became: "I just need 5 more minutes!"  Of course, five minutes often turns into hours.  I think we all might have gotten more sleep if we had been willing to give up on continuing down a certain path and try something different instead.  Sometimes, you have to know when to cut your losses.

Don't Have Too Many Cooks in the Kitchen

It took us a while to learn this, but by the end of the event, Tina and Tuan were just styling pages while the other three of us wrote code.  There just wasn't enough "space" in the application for us to avoid stepping on each other's toes.  I have already made reference to the "Mythical Man Month" but let me reiterate--having 5 developers does NOT mean that the team gets 5 times as much work done.  There's a lot of overhead because with more developers you need more coordination, communication and management.  Often, one person has to wait on another.  Truly you cannot make one baby in one month by getting 9 pregnant women together.

Good Programming Takes Time

Of course we all know this.  But one aspect to having such a short time frame to build an application is that the problems you run into every day become incredibly more visible and real when your project must be completed in hours instead of weeks.  I am amazed at how our team came together and at all the projects that the various teams finished for their charities.  That being said, i have no doubt that our code would be more maintainable and our application more stable given more time and more sleep.  About halfway thru the first day of the event and I realized I had signed up for and dragged in poor Tina and Matt into my worst nightmare: the ultimate unreasonable deadline.  I'm sure our charities will need further help as bugs are fixed and holes are plugged in the weeks and months ahead.

Finally, I Need Practice Speaking in Public

The team cruely nominated me to demo the application before all the teams, charities and attendees while being filmed.   Nervousness and exhaustion had obviously taken their toll on me as a rambled on for about 30 seconds before I got focused enough to talk thru the application.  I tried to be brief but i think the end affect was that I talked a little like the micro machine guy so I could get off the microphone.  I'm due to speak at the Fort Worth Dot Net User Group soon so hopefully i'll be more relaxed and clear for that event.

Wrap Up

I'm not sure whether I would volunteer at an event like this again.  The stress of the short timeframe and the lack of sleep made me chant "NEVER AGAIN!!!" like a mantra shortly after it was all over.  But looking back I learned so much and it was for such great charities that I might consider taking another stab at it next year.  Or at least, maybe helping out in my spare time.

Read the complete post at http://dotnettricks.com/blogs/craigbowesblog/archive/2008/01/21/703.aspx