I spent my weekend in my company’s office. Keep in mind that 1) I’m a consultant and I’m usually at a client and 2) I didn’t get paid. Why would I spend my weekend at work? Meet and Code
What’s the point of Meet and Code? The point is for a bunch of people (developers, DBAs, UI people, PMs, BAs, etc) to get togther and work on a project to learn, build new skills, and do it right the first time. Sometimes, the real world constraints of deadlines and budgets don’t always give us the time to do TDD and to do things properly. So we rush through things and have to test manually. Not at Meet and Code. Instead, we’re doing things using agile practices, TDD, and rapid development techniques so that we can practice the craft that we preach about.
See, a few months ago someone had the crazy idea that we should get together and work on a software project over the weekend. Now, that catch was that we had to recruit other people. So, we recruited other co-workers. Eventually we’re planning on recruiting the rest of you, but bear with me.
After we recruited a team of suckers volunteers, we did a few planning meetings before everything got started and decided on a product to work on (an event RSVP web application so we could manage the next time we do this). We also figured that everything would take about a weekend (Friday 5pm – Sunday 5pm).
Friday was pretty much a wash. There was a TDD and mocking demonstration that was incredibly helpful, especially since I haven’t done TDD in a long time and mocking is just right outside of my area of expertise. Most people didn’t have development environments set up on their computers, there was some confusion about who was responsible for determining what, but things got ironed out by the end of the night. Towards the end of the night, I started working on the database and the UI people were able to get started. I left around 12:30 or so. Things were pretty disorganized, but it was a good start.
We finally got a build server set up early Saturday morning. I kept churning out database code while the business layer was being put together. There was still a bit of confusion, but by the end of the day things were going full steam. People came and went, but that’s what we expected.
The office was pretty humid and smelled distinctly of feet by the end of the night. It didn’t help that the air conditioning is turned off on the weekends.
By Sunday, I was starting to run out of steam. It’s tough to make it through a week of your day job and then run through a development sprint on the weekend, but the fun and learning made it more than worth it.
How did it turn out?
It went well. There were definitely some initial teething problems – development environtments weren’t set up, use cases weren’t fully fleshed out – but we made it through them.
Going forward there are definitely some things that we could do differently to make things run smoother:
- Install fest – We should have held an early install night where we focus on getting everyone’s development environment prepared. This would prevent problems with service packs installing and getting different versions updated.
- Training materials/demo – In addition to the install night, having fully built a single feature to demonstrate the ‘proper’ way to use ASP.NET MVC would have been very helpful for everyone.
- Dedicated user representation – We initially had some BAs present on Friday night, but they had other weekend plans. It was difficult at times to resolve some ambiguity in the use cases or to determine how a feature should really function. If someone else was designated as the user representative, we would have been able to defer to the user rep on all of these issues.
However, despite these teething problems, we had a lot of fun and I definitely think we’ll be repeating this a few more times before we take it completely public with some hints and tips on our methodology for running the event smoothly.
