When I joined &yet this last January, &! (And Bang) 1.0 was already launched. A lot of the work had been done by one or two members of the &yet team.
But, And Bang was a product of the company, not just a couple of people, so we had to find a way to better enable contributions from the rest of the team. Its core ideas were us—so very us—so why shouldn’t more of the team be enabled to contribute on a significant level?
Significantly increasing the number of contributors is more difficult than you might imagine. I pushed very hard to empower team members to contribute as much as possible. These efforts paid off, the team was energized to help but we also learned a few thing along the way.
For starters, we did simple things that had a huge impact. We developed a set of general standards for code that we could enforce. We used jshint and passing test cases as a roadblock to get code into the project.
We also added a github inspired pull request flow as a code review step. These few steps serve as a gateway for getting code into the project. However, by the time you send a pull request you've already built what you think that feature or fix should be.
Engineers see problems very differently from one to the next and thus, come up with drastically different solutions. Some just "make it go" and some really optimize to the nth degree. To improve this and spare misguided work we adjusted our issue tracking process.
We broke out tasks and features into smaller issues in Github and gave free-for-all access to help build And Bang.
We quickly had a lot of the team contributing at an amazing pace.
During this time we had one major interruption that all but killed enablement of our team to contribute: we refactored all the things.
This refactor was again completed by the small core team that was curating the features and design of the product. The scope of these changes temporarily blocked others from contributing. While frustrating at the time and while it felt like a black cloud looming over the project it ultimately had a positive impact in enabling contributions from others.
The core of the refactoring involved decoupling the API from the client and writing a spec that strictly defined the API. This allowed us to use it as a gauge of completeness of the implementation. Now the API could be designed as a separate step, and our team was free to implement to that spec.
In addition this specification allows for interactive documentation to be always up to date and automated testing of all aspects of the API to a much deeper level than before. This means that developers know if they broke something immediately as the tests are run during every commit.
I think it's important to evaluate the efforts of the fast-moving prototypers in terms of the resulting impact on others ability to contribute. Also, to be aware of the "wake" that this creates and communicate that to the team so as not to discourage those trying to help. This may manifest itself as un-mergable pull requests which represent wasted time and effort.
Issues now go through a workflow that is similar to
Issue is reported. If that issue is a feature request it’s scrubbed by the curators of the app.
If it’s a bug we try and put as much design decision into the ticket as possible or via discussions, then it’s on to implementation, polish, tire-kicking, pull request, review, approval and finally the glorious pushing to production.
At this point we can fire on all cylinders and be confident on what is working, as well as what doesn’t work. People can contribute in their area of expertise whether that is API, client side, design, whatever without fearing breaking things they don't understand.
The best part about all of this? We aren’t done improving. Software development is very much like a mobius strip. You come back to where you started, having learned a lot more from the trip. We're just sharing what we've learned so far.
Add your email to join the And Bang 2.0 private beta invite list: