Ingredients for startup project Tembow:
- 2 founders (Rachel and Jason) with an idea
- 2 Agile developers (Pete and Beth)
- 7 weeks
- 1 goal; to make a website to assist clients in writing and sharing blog posts
Recipe Directions:
1. Write stories and plan iterations
2. Begin pair programming
Pete and I began pair programming with two keyboards and one computer. This allowed us to set up our environment and create the initial models and integration end-to-end tests. Although, when starting a new project there isn't a lot of code to dig through, these types of things were made easier in pair so that we could establish coding conventions that we would follow for the remainder of the projects. We both became familiar with the structure and tests before trying to add the next thing. We could make progress without going back and reviewing what someone else had coded at each check-in.
3. Continue pair programming for two weeks
For the first two iterations, Pete and I coded as a pair. Occasionally questions would come up and one of us could ask Rachel or Jason to clarify while the other continued finishing a few lines of a test, for example. This kept us moving forward and the answers would come back without interrupting the flow. Also, when Rachel or Jason emailed us with questions, since there were two of us, there was a better chance one of us could respond right away, which meant faster response times.
As we began building more complicated models, some design questions arose. How will we store posts? Do they belong to companies or users? Decisions about model design were easier and more informed in collaboration when we could both pull from our existing experiences and our projections of the future of the projects. Not only did these discussions stay brief, they kept us both focused on the task at hand without wandering to the next thing. Pete often kept me in check while I (new to Test-Driven-Development) would attempt to write some code without writing a test first. These partner checks kept the quality of our test base high, which was crucial as the project became more complex.
4. Add spices and continue
After the first two weeks, I went on vacation. If I had been the sole developer, the project would have halted, but instead Pete took the reigns and had some guest pairs while I was gone. Not only did this allow me to take off without a major disruption, it allowed more people to see our code and add their knowledge to the project while keeping the forward momentum.
When I returned, we initially took up pairing again so Pete could explain anything that changed while I was gone. This reduced time I may have spent digging through code if we had soloed right off the bat.
5. Solo when work can be done in parallel while keeping communication frequent
As most of the framework and code base became stable, Pete and I decided to solo more often, working on two computers in the same office to maintain collaboration. Although this isn't the standard Extreme Programming way, we did this for a variety of reasons. We were both familiar with the majority of code already and the major design decisions were already made. Also, many of the tasks coming up were smaller page-specific tasks, like adding forms or button actions to a particular feature. These tasks were narrow in scope and wouldn't touch major design structure, making them less risky to code quality and easy to do in parallel. Likewise, due to the short nature of the project it was less important at this point for both of us to see the code that the other person was writing. Efficiency and tackling more features became our priority over knowledge sharing and we could do this without compromising much in terms of quality.
During our retrospective after the project ended, it became clear that as a team we believed we benefitted from our decisions of when to pair and when to solo. When we decided to switch out the database four weeks into the project, the transition went very smoothly. We all agreed that this was due to our focus on building a quality code and test base through pairing in the beginning. And it was easier and less messy to code in parallel when the rest of our code was solid. We made very speedy progress toward the end of the project which pleased us all. Overall, we found that the way we paired and split up mirrored our varying priorities as we tried to balance building quality maintainable code and developing features quickly.
6. Remove from pan and enjoy!
Comments