SCM Problems at the Heart of BlackBerry 10 Delay
I admit, I was surprised to hear the CEO of a large company talking about nuts-and-bolts SCM issues. I was even more surprised to read that nuts-and-bolts issues were behind the hugely publicized delay of the BlackBerry 10 platform. Here’s the original article: RIM CEO on What Went Wrong and the Future of BlackBerry.
And here’s the paragraph that really caught my attention:
“The delay of BlackBerry 10 is not because we added stuff to it. The delay is because our software groups were actually so successful in coding the various feature components and building blocks that when we put them into the main "trunk line," as we call it, when we wanted to build the first main release, we got overwhelmed by integration efforts. I had to make a decision. I could actually have kept the schedule, if I had made a sacrifice on quality and on platform stability. And I decided not to do that, because I need to make sure that when we deliver a BlackBerry, it is best quality.” - Research In Motion CEO Thorsten Heins
The main “trunk line” in the SCM tool he mentions is the implementation of what in Perforce would be called the "mainline" in the "mainline model", as described in Perforce’s Version Management Best Practices white paper. The mainline is where all the change intended for a product eventually collects. The process of collecting all the change is called “integration.” And as Heins reports, that’s not often an easy process at enterprise scale, and exactly the sort of problem that leaves you having to make lemonade out of your product delay in front of journalists!
I can completely understand why RIM got into trouble. Version Management turns out to be a lot harder, and more important, than it seems on the surface. I’m impressed Heins recognized this, described it accurately, and was able to make a firm decision about it. That, at least, bodes well for RIM’s future.
GitHub’s recent $100 million dollar VC funding is another data point that version control is far from an insignificant, commoditized afterthought, but a beating heart that can power software revolutions. No one knows this better than Perforce, as the software in Andreessen’s Why Software is Eating the World essay has largely been developed using Perforce.
Since Perforce already has an enterprise-scale heart, we’ve been working steadily on ways to bring that power to more people. You’ve probably already heard of our Version Everything mission, bringing the power of version management, long enjoyed by software developers, to more document types. Teaching Perforce to speak Git makes us a powerful and transparent way to support native Git developers, a result more powerful than either part separately.
The end result, we hope, is making uncomfortable delays, such in the case of the BlackBerry 10, rare and controllable occurrences.