techno.blog("Dion")

Tools enables new ways to build. Distributed version control and the tools that are enabled on that platform (as highlighted by Github) have hit mainstream. Some graybeards will scoff and talk about how they did this and more decades ago…. And they typed up hill both ways! Now, it is available for all.

I have seen the shift in the way that projects can now be run, and how software product can be shared. Take an example, such as where I work now. Ben and I run mobile engineering for Global eCommerce at Walmart. This means that our products scale in different dimensions. One axis is the number of platforms for a given locale: iPhone. iPad, Android, mWeb, etc. Then within that locale a platform can have multiple products: grocery app, general merchandise app, etc. Yet another axis is the various locales. The apps and platforms for the different countries may not fully align. As you can imagine, we think about the topic of “leverage” across these axis a lot. There are extremes.

One True App

This is the mega platform. It is generic in a way that lets you customize it for varies experiences, but it has to know it all. I have rarely ever see this approach as it means that you need to think up and agree to the constraints of he system for all parties up front. Can you take a look. At the businesses from China to the US and say they can happily live with the same guard rails? If so, great, you have gotten a winner. Even so, you quickly find yourself in a resource allocation quandary. The owner of the core platform is the parent, and each locale is now a child shouting for resource. The largest baby bird often wins, even if the runt is actually growing, or had the potential, to grow fastest. The sibling rivalry can become a pain too. The parent may want to push back to the children, and can try to do so by developing the core APIs and letting the kids have at it on their own. Awesome, loose coupling. The other massive benefit is that the kids can go outside of the family. We see this a lot due to the fact that the parents use popular and/or standard libraries with well trodden API. This is where API shine the strongest anyway. Great a small piece of functionality that can be shared and extended. If you are building a mobile Web application client, why wouldn’t you build off of a Backbone, socket.io, zepto, underscore, handlebars stack (or your own favorite equivalent version)?

The Third Option

There is a middle ground between “here is my code” and “here are some APIs”. The greatness of the pull request enables this in spades. Give the kids some safe rope to help them climb. If the platform is evolving fast and one kid wants to go off in a direction they can fork away and use the tools available to diff and merge. When over for Sunday dinner and you are all chatting about what you did that week, you can see if it makes sense to pull something into the mainline.

The parent product now has evolved into others that are able to steal good ideas from each other all the time. When taken to an extreme you see Linux. Linus has his Truth, but his lieutenants have their own, and there are folks who have their own under that.

This is all non-trivial to manage from a process standpoint. It also takes time to keep up to date and sync early and often so you aren’t looking at a mutant form that can’t breed with the core no ‘more. There are many new tools that could enable us to visualize and work with the forks, but it seems like we have hit a new norm, and the nuance of this approach can be just what the doctor ordered for certain platforms and products. It enables truly fluid structures. You can get up to speed with something new quickly, without having to fully by in.