Raible Designs

[DJUG] Ship it! and Distributed Teams by Jared Richardson

Jared's first book is called Ship it! and it's been wildly successful (translated into several different languages). During the first hour, Jared talked about his book and practices defined in it.

Ship it! is an attempt to talk about the holistic process of software development: techniques, infrastructure and process. For Techniques, there's a Technical Lead, The List, Code Reviews, Code Change Notifier and Daily Meetings. Infrastructure involves Version Control, Script Builds, Continuous Builds, Track Issues, Track Features and Writing/Running Tests. Process is Propose System Objects -> Propose Interfaces -> Connect Interfaces -> Add Functions -> Refactor, Refine, Repeat.

Martin Fowler's definition of Architecture: anything that is difficult to change later.

The majority of Jared's talk was about implementing TDD, continuous integration and many other things driven by audience questions. I didn't take notes because it was more of a conversation than a presentation. Jared's second talk was on Distributed Teams and my notes from this talk are below.

Agile is not XP or Scrum, those are implementations of Agile. The Manifesto for Agile Software Development is the interface for Agile Development. It contains the following principles:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Custom collaboration over contract negotiation
• Responding to change over following a plan

To re-word these principles: Agility is...

• People interacting
• Software that runs
• Fast Feedback
• Frequent Change

Scrum principles are often not about developing software, they're about making people talk. The important thing is to get people in the habit of communicating. The best way to get people interacting is to do Daily meetings. One to two minutes per person. Same time. Three questions (what did you do yesterday, what today and any blockers?). Scrum style.

How do you do a daily meetings when you're remote? Conference calls are the most common, but don't let anyone local dial-in or they will get in the habit of doing it. Video is best, but it's often expensive to setup. One good strategy for daily meetings is IM. The beauty of this is that there's a transcript of the daily meeting that others can read. Conference calls are usually bad b/c you can only hear the guys that are close to the phone. It's even worse when the speaker phone is a cell phone. Whatever you do, you should never skip the daily meetings.

Peer Code Reviews are another good way to get people interacting. The first rule of code reviews is that anyone can refuse to do one. If you're not doing code reviews or pair programming, you'll end up with inefficiencies and broken windows. Address the behavior head-on. Peer Code Reviews remotely: e-mail, Skype headset, IM, VNC or SubEthaEdit (works awesome). NetBeans (collaboration module) and Eclipse (communication framework) have plugins that allow SubEthaEdit-style functionality.

How do you keep software running? Continuous integration and automated testing. Keep a list of atomic features. Prioritize. Don't let people work for 2 months. All tasks should be broken down into small chunks. Tests are a good way to communicate. Don't tell me you're done because you think you're done. Show me a test that proves you're done. Don't allow broken windows. Broken windows give the impression that no one cares and more bugs happen because of this. Continuous integration is essential for remote teams.

What's the best to get fast feedback? Fast compiles, fast tests, running CI 24/7. Another good strategy is the The List. Make sure and get feedback from your Tech Lead and from your Customers (they like to be involved). If you have a list that doesn't change after 6 weeks, you're working for a team who's list is dead.

There's nothing wrong with documentation and a plan, but its the things on the left that are more important. Offsite teams should have a single tech lead. Writing Tests might be better than writing requirements. When the tests pass, you'll get what you asked for. If you care about the design, write unit tests. If you don't care about how it looks, but want it to work, use integration/MCT for functional tests. Don't separate development and QA. To deal with time zones, make the tech lead stay up and rotate. For documentation, DRY out your Docs. Generate documentation instead of manually creating them.

"Docs are a cache ... flush often"

For Customer Feedback, have the tech lead translate.

I really enjoyed Jared's talks. The first one (on Ship it!) didn't provide much new information for me, but that's likely because I've worked on several open source projects and I've tried to bring those procedures and practices into any company I've worked at. I'm very grateful that LinkedIn does a good job with continuous integration (Hudson), bug tracking (JIRA) and documentation/planning (Confluence).

The 2nd talk on Distributed Teams was enjoyable because I'm in the heart of that - managing a remote team in Denver. We've experienced the awful conference calls where you can't hear anything or when we're on speaker on a cell phone. We do have all the video conferencing equipment purchased (10K worth) and sitting in our office, but haven't set it up because we're waiting on IT to setup a persistent VPN (which is a requirement to make it work). I've had some communications issues with my boss (mostly related to him not knowing what we're working on). We do daily stand-ups and use many of the practices recommended by Jared. One thing I think we can do to increase communication with headquarters is to start doing our daily meetings over IM and posting the transcript to a wiki page.

If you get a chance to hear Jared speak, I highly recommend it. He has a style that's very conversational and fun to listen to. You feel like you're a part of a self-help group rather than listening to someone preach about how you should be developing software.