hindsight is 20/20. It would be quite easy for a team of developers and product managers to get together to discuss "how we take what we have and extend it to cover the new use case" rather than "what is the best approach for the new use case".

But even before reuse, the "DNA" point can't be overlooked, though. Success breeds a belief that "our differentiators" need to be considered and baked into subsequent products. More often than not, those constraints lead to situations where you're fitting a square peg into a round hole, as with Skype and P2P messaging.

What saves some companies from this is a core DNA that can be interpreted in a very liberal and malleable fashion. For instance, Amazon is about distribution--be it products, bits, computing power. Facebook is about social connection (not P2P or a particular narrowing of tech). Of course, maybe that's just survivorship bias...no one keeps a good directory of the graveyard of corporate DNA that was as similarly broad.

Now whether that is a function of articulating flexible DNA, or the flexibility of the decision makers...I don't know. Either way, fixed mindsets close down adaptivity to new opportunities.

We did acquire GroupMe with the same thinking: take that startup with a good group messaging product and integrate them into Skype.

Except this never happened, GroupMe is still a standalone app and pretty much a standalone team. I am not sure why we didn't or could't integrate them, the Microsoft aquisition of Skype, and the subsequent integrating with Lync (and the birth of Skype for Business) probably had higher priority.

Reusable components is a mantra within software engineering. People deciding on product direction want to reuse what's available and has been tested: known quantities increase confidence levels. Unfortunately, the reuse in the large vs. reuse in the small dilemma gets lost in the decision-making. At a certain job level, applications become components represented by geometric shapes on a whiteboard or electronic diagram. At that level, components look like good candidates for reuse.

Unfortunately "the devil is in the details". Reuse, in this case, hurt the messaging app because of a fundamental difference between connection and connection-less communication. I'm sure the engineers working on the messaging app understood the problems. But, they were most likely not a key part of the decision chain.

This whole Skype/P2P thread makes me feel very pleased and very optimistic about what we have built already and are building for release relatively soon.

You can do P2P on mobile and you can even do P2P with central server fallback without sacrificing reusable components and with standard network protocols. You just have to do the hard work at the lowest layers first and you have to think about the problem from an SDN perspective instead of an app-centric-P2P perspective.

(Intentionally cryptic response, yes. Grin.)