Collective Ownership: Developing Software as a Team

Over the past few days, I’ve had the chance to observe some more senior software developers as they’ve worked on building and modifying real world, living codebases. It’s been an extremely educational experience on many fronts, but the thing that’s stuck out to me the most so far is how involved everyone is with everyone else.

Successful software, it turns out, isn’t the product of one genius individual; in most instances, at least, it’s something that grows out of the coalescence of a team.

Of course, a team could just be a collection of individuals - each toiling away on their own tasks that will hopefully somehow fit together. But in order for a team to form a whole that’s greater than the sum of its parts, something more needs to happen: team dynamics need to be instilled.

In this post, I want to review some of the behaviors that go into being part of a successful software development team. While such behaviors may not be especially necessary in the context of the individual projects I’ve worked on thus far, they seem like they’ll hold a lot of relevance in the (team)work I hope to be doing in the future.

Step 1: Stand Up

In order for everyone on a team to be on the same page, it’s helpful for each team member to know what page each of their teammates are on. It might sound trivial, but having a bit of time to catch up with your teammates before getting down to writing code is crucial. Stand up meetings fill this role.

Stand up meetings offer opportunities for teammates to share the progress they’ve made, explain what tasks they’re hoping to accomplish in the immediate feature, and solicit counsel when some obstacle is standing in their way. When kept brief and to the point, they offer a great opportunity for everyone to stay up to date with one another.

At a far more basic level, they assure team cohesion. When you engage with your teammates every morning, you’re sure to be keeping up with each other. Having a sense for what everyone else is up to and how their tasks fit into the larger project makes it’s easier to envision how you and your teammates’ contributions will fit together.

Step 2: Document Objectives

The developers I’ve worked with divide up tasks into a set of “stories”. Each story lays out a feature that needs to be built, as well as any specifications that further clarify the nature of that feature. The total list of stories is accessible to the entire team, and each story is marked as either to do, in progress, or complete.

In my individual work, I’ve used a rudimentary version of this setup, documenting tasks I hope to accomplish in a to do list and crossing things off as progress is made. But having a more sophisticated layout allows you to share that knowledge and tackle those objectives with your team.

Stories that are accessible to the entire team help to provide a shared sense for the tasks that lie ahead, and documenting who’s working on what further assures that no work is overlapping.

Step 3: Use Branches

People who are working as part of a team don’t all push their commits to master; they set up branches that describe what task they’re working on. When the work is finished, they can submit a pull request for the team to review.

Working with branches helps to document and organize buckets of work as progress is being made. A large number of commits might fit into the development of a single feature, but branches makes it easy to consolidate them. Their label communicates how everything assembles into one goal.

Branches also make it easier teammates to review and merge contributions. If the progress looks good without modification, merge. If it needs some more work, revise and resubmit. If it’s looking like you need to go in another direction, no worries: revert to master.

Step 4: Stay in Touch

Teammates further contribute to the fostering of team dynamics by deepening their communications with one another as necessary.

Think knocking out your story will require some architectural changes to the larger organization of the project? Get in touch with your team. Maybe they see some merit to your suggestion and the change is approved with everyone on board. If not, maybe they can suggest some approaches that work within the existing architecture.

Notice that a teammate has wrapped up a story and submitted a pull request? Give it a review. You might have some additional perspective that assures everything will synthesize together as well as possible.

Though the work of writing code may be something you approach on your own or with a pair, it never hurts to bring in an extra set of eyeballs. Teammates should put emphasis on staying in touch with one another to assure that progress fits within everyone else’s vision of the project.

Recap: There’s So Much More

As I’ve put together my individual projects, I’ve found feedback loops to be really helpful. Getting other people’s perspectives helps me to see ways that I can improve my code and add new features because those folks are approaching my project from a clean slate.

Working with a team, those feedback lopes aren’t just helpful - they’re essential. Teammates foster team dynamics by meeting up regularly, documenting tasks, working on branches, and staying in touch throughout.

But that isn’t all that goes into being part of a team. There’s a lot more to learn, and I’m excited to get a better sense of how the most productive teams stay cohesive going forward.