I’ve been programming for many years, and have spent most of the last few years managing development teams. I’ve written plenty of closed source software, and for a time made my living writing open source software too.
One thing stands out: a shared code base does not a software team make.
It’s the designing, not the coding
The most effective, driven, and powerful development teams I’ve been part of spent much of their time designing, not programming. And we were designing as a team.
The most powerful software teams are not those that are programming together — it’s those that design together, and build systems together. Throwing a group of developers at a code base, and just expecting it to work, won’t.
Remove the human element at your peril
This is why a tool like Geekbot is counterproductive.
While it seems like a clever idea — allow your standups be asynchronous, so people can get back to programming — it removes a key human element from design and implementation, and the team suffers. I witnessed this myself — because there was no-one on the other side of the stand-up, the status updates quickly deteriorated in quality, and became next to useless. And it was worse as it actually undermined the feeling of being part of a team.
Help your new hires understand the system, not just the code
Since designing a system is the most powerful way a team bonds, how do you engender that same feeling in new hires, even after a system has been designed? You must explain to new hires why a system works a certain way, not just how. Describe how the design evolved in the past, the decisions that were made, and wrong paths that were chosen. Doing this deepens their appreciation for the work ahead of them. Don’t focus only the code, focus on the system.
Successful programming is a human activity, so be sure to keep it so. Don’t remove the human element. And don’t forget that it’s teams that build the most important systems, simply working together on shared codebase does not.