All Hail the Red Queen... (from my Borland blog)

“Now here you see it takes all the running you can do, to keep in the same place. If you want to get somewhere, you have to run at least twice as fast as that”

- Red Queen – “Alice Through the Looking Glass”

I spoke at BZ Media’s EclipseWorld last week about the impact of “the Eclipse Effect” and the challenges and opportunities it presents both Enterprise IT and ISV’s as they build out their next releases of products. After the keynote, a theme that came up in multiple discussions is the acceleration of how often companies need to re-consider their competitive positioning and their differentiable value. It seems like this was once a generational question for software companies and IT departments that arose every 8-10 years. Now one needs to manage “differentiable value” more like a series of cash flows used to value a financial instrument. Your product portfolio’s feature sets are a bucket of these value flows that need to be assessed independently and on an ongoing basis. This creates a “net differentiable value” which can be used to determine product creation priorities and go-to-market strategy.

Every few years it seems like someone comes up with another thing to apply financial derivatives mathematics to. My bet is determining optimal commercial differentiable value and the use of open source will be two more of them. Hey, any of my old friends from O’Connor, Swiss Bank or CIBC, want to take a crack at it? Give me a call.

So where has this acceleration come from? What were the pre-conditions? I have two themes I think are part of it that I will write about in subsequent posts: “Cyberphysics” and “The Kids are Alright”. Stay tuned.


UPDATE ON THIS POST: After my previous Borland posts and then this one the core of people whose rabid concern was the future of Delphi and Borland C++ began to emerge. The main complaint being that my Borland blog should be used to pretty much talk about release schedules, features and futures. Unfortunately for those folks I didn't see that as the role of CTO, and now with time in retrospect, I still don't agree with them. Borland had over 100+ people involved in the development, marketing, support and management of these products - their words and messages should be sufficient. Another thing I noticed in the comments was a refusal to accept (not understand, but accept), that officers of public companies cannot reveal specific about product plans without doing so in a careful, planned, and legal way. Regardless, below this update I include a response to one of the comments longer than the original post. And in a single comment by "Anonymous" here - I have put all of the critiques.

My response to one of the critics:

A couple comments in response.

Yes this is a “BDN” blog sponsored by Borland Developer Network. That said I really can't provide any specifics on product direction for any Borland product that has not already been publicly stated. In my handful of blog postings as you can see I focus on the trends or themes I see in our enterprise customer base – trends and themes which I believe will ultimately have an impact on enterprise developers, if only as a result of organizational behavior, as well as their technological effect.

In this post I was ruminating without conclusion on one of the things I am seeing our customer’s struggle with as well as our ISV partners; what is a company’s differentiable value? I still don’t have conclusions – but here is some of the underlying thought in process.

In prior generations before open source, you looked at competitors and customer demand. If a competitor had a feature you were for the most part expected to counter it with your own variant. This is “me too”. In order to have differentiable value you had to think up and implement customer-desired features before your competition, “me first”. So determining product features was a “me too” vs. “me first” balancing act. Hard to be good at, but the dimensionality of the problem didn’t make your head explode.

Given the advent of (to name a few):
Internet connectedness as a force to:
- focus the accumulation of intellectual capital
- provide planetary scale development on relatively small problems
- Growing enterprise acceptance of open source
- The “API-ification” of almost everything

How does this change “me first” vs. “me too”. It introduces, to oversimplify, “should I ever”, “who else”, and “along with”.

“Should I ever” – means “is this a capability that I believe will have a valid commercial life before commonly understood and implemented in open source?”

“Who else” – is what are the other sources of components for my integrated product – probably an order of magnitude more complicated as a result of independent open source contributions, foundation open source contributions, and corporate open source contributions”, as well as partner and community contributions via the “api-ification” effect.

“Along with” is perhaps a combination of your contributions to community and open source initiatives, as well as your investments into the api-ification of your product lines.

All of these are new dimensions which potentially require one to BELIEVE something about the future, which in my book means you need to start reviewing all of this probabilistically to get some sense of what your expected outcomes are.

Once you are into “probabilistic, expected outcome” you ought to start thinking about standard techniques used everyday in other domains to help you. Look at Borland’s CaliberRM, one of the most compelling features is the use of Monte Carlo simulation on industry standard historical data and company-specific historical project data to provide a probabilistic estimate of project success given the time, budget, staff, etc.. Does this probabilistic approach guarantee anything? If all the inputs are completely wrong then it does nothing. If the estimates are close – it gives you some sense of the possible outcomes.

So as I think about the granularity of major feature areas of all of a vendor’s products with respect to “me first”, “me too”, “who else”, “should I ever”, and “along with” – combined with the fact that all of these judgments require some belief about an inherently exactly unknowable, albeit estimable future, it turns my thoughts to the techniques used in derivatives analysis.

As an over-simplified primer here are two pointers. Modern financial mathematics got its jump start when Fischer Black (U of C) and economist Myron Scholes (MIT) collaborated on the concept that option pricing was essentially the same as the thermal conduction law of classical thermodynamics. Also, (thanks to Peter Hoadley) play around with option pricing graphs at http://www.hoadley.net/options/optiongraphs.aspx .
Notice the impact of “volatility” which is your probability estimate. Notice sensitivity to “time to expiration”.

This calculator is for a relatively simple set of cash flows, which in some ways can be thought of as probability flows. Complex financial instruments require you to analyze thousands of future cash flows, with future beliefs about potentially numerous cross rates, interest rates, inflation rates, credit ratings, etc.. At that level of complexity, with that many guesses of the future, it is necessary to know maximal risk exposure depending upon numerous probability paths.

SO…since option theory is increasingly used in other domains to understand types of probabilistic risk exposure I was wondering if it is about time to have a more formal, statistical approach to product management given what I believe is the increasing dimensionality of that problem. Does this affect developers directly? If I am wrong and we live in the simple world of “me too” vs. “me first”, then certainly not. On the other hand, maybe it is worth a thought with respect to the products one is making human and financial commitment to – whether products built or products bought.

And, because of my “give a moose a muffin” type thought processes I also wonder how did we get here? How did this acceleration start? Why are there so many people willing to work in a collaborative way to solve problems like an open source OS, open source appserver, etc..? Where did they come from? What are the generational or cultural shifts that have caused the acceleration of openness, api-ification, and collaborative connectedness? Which as I said, I will post some gobbledygook about in the future.

Thanks for the comments.

pk