When I first started consulting, I used to squirrel away in my corner and code. Some weeks later, I’d deliver my perfect shining gem to the client after, quite frankly, trying to talk to them as little as possible throughout most of the process. It wasn’t that I didn’t like people, I especially enjoyed talking with developers, but the gap between what I knew I needed to do to get the job right and my ability to explain it to the client seemed insurmountable. With repetition, my ability to explain technical requirements in a management friendly way has evolved to something like passable, but an equally important change has been Github.
Github has allowed us to take a different path with our projects. We now treat them much like open source projects. We strive for transparency and clarity in everything we deliver as well as in the process by which we deliver it. We often do complex UI rewrites and performance evaluations for big companies like Facebook, Paypal, Adobe, Salesforce, Trulia, Williams Sonoma, Pottery Barn, etc. Big companies have a lot of stakeholders and we’ve found that Github is an amazing way to include them in the project from the beginning.
Our clients have access to the code we are writing from the first line we commit. When my developers and I code review each other’s work, the client can see and also participate in that code review. In that way, they get to understand (and buy in on) not only the end result, but the rationelle behind it. Clients also send their developers to work side by side with us. We take them in as a part of our team, submit them to the same grueling code reviews we all go through.
We’ve found that they are happier this way. The transparency I feared, the risk taken by trying to explain something and failing, has been far outweighed by the practical benefits of healthy collaboration. They now feel the end result belongs to them, rather than being something forced on them from outside or upper management.
There is also something great about letting a client peek inside the works… they find bugs, omissions, and misunderstandings. Why is that great? Because they find them right away, rather than several weeks or months into a project. They also feel empowered to open github issues for those bugs, helping us do our job even better. Instead of it being a terrible thing to find bugs, it becomes an ordinary part of the process. I usually explain it like popcorn popping. For a while you will have a lot of pops, and then slowly it will wane and you’ll just get a pop every now and then. When the pops become pretty infrequent, we move the code from our repo to theirs. I hope this means our clients trust us, because they get to see that we will continue to show up for them throughout the project and that we’ll always have a curious, relaxed, and grateful attitude when they identify something that needs fixing.
We didn’t want you to work on that!
It also means that there isn’t any issue of “we didn’t ask you to work on that”. The client gets to approve all work (in the Github issue for the feature) before we even get started. They also get to see the kind of bugs I assign to Fiona, or she assigns to Arnaud and get a sense of the teams strengths and weaknesses. That helps them know who to contact when an issue comes up. Yay for anything that makes me less of a bottleneck. :)
And the most important reason? Code quality
I’m a firm believer that open source code is of higher quality than code written in a vacuum. I can’t say if that is true for every project out there, but it has certainly been true for us. Greater transparency has enabled us to have a tighter feedback loop and make a few things I’m quite proud of.
Anyway, I could go on and on about this because I’m quite passionate about how an open source approach and Github in particular has enabled us to improve our work, but I’d love to hear from you. Have you used github in this way? Do you use it internally? What works? Any tricks? I know their are a few features I still wish existed, how about you?