Tuesday, March 25, 2014

I'm Looking for a New Job!...

...And you're reading this because you thought I was serious.

A number of months ago, an EVP and member of the Executive Management Team emailed me to say he wanted to spend a few minutes chatting with me.  He and I had met, face to face, for the first time the week prior and I left a positive impression on him that he wanted to explore further.  In the spirit of full transparency, I allowed this meeting to stay visible in my work calendar in spite of the risk of my management chain seeing it and misunderstanding.

So, of course, my manager did see it and did misunderstand.  He called me up a week after the appointment was made (but still before the actual date of the meeting) and seemed distraught that I didn't trust him enough to tell him if I were dissatisfied with my role.  This was the inspiration for a previous blog entry where I contrasted the concept of happiness versus contentedness in one's role.  Another part of my discussion with my boss, that I did not describe in that blog entry, revolved around the activity itself.

Humpty Dumpty? Who's that?
During that part of the discussion, I compared my meeting with the EVP to a sales pipeline.  Was I looking for a new job?  Not necessarily, I said.  But just as a sales professional builds a pipeline that is 4 times their quota because they know that 75% of those potential deals will fail, one cannot take a sequential approach to something as strategic as looking for the next step in their career.  Instead, you have to be willing to entertain all things even if you're not explicitly looking to change jobs at that particular moment.

Or, as the cliché goes:  "don't put all your eggs in one basket."

Expanding this to a more general discussion, devising an effective strategy for anything is part marketing, part sales, and part operations.

Marketing.  Development of an effective strategy requires effective communication of that strategy.  And that starts by understanding what, exactly, it is you're trying to achieve.  For example, when building a public relations campaign, one of the first things you do is answer the questions:  who needs to know, who needs to be involved, who will be effective, and what is the take away for each of those three groups?  Answering these ensures that you thoroughly understand the topic to which your strategy applies and are able to articulate it well.

Sales.  The actual activity of articulating that message, however, is more sales than anything.  Unless you're in a position to simply dictate your expectations and press the proverbial "Go" button, you're going to have to convince others of the strength of your position.  This means that you need to not only understand the topic, but you must also understand the benefits of its execution and the risks of not doing so.  Measurable data points allow you to objectively communicate the latter part of that and also allow you to track it going forward if your strategy is adopted.

Operations.  Tracking its success is incredibly important, as you'll undoubtedly agree, because you will need to know as soon as possible if things don't work as expected and address the problem immediately.  This may require on the fly adjustments or a complete reversal of your position.  Since a compete reversal / rollback would result in a hit to your credibility, contingency plans must be developed and ready to execute should the need arise.

You're probably asking yourself, "is all of this really necessary?"  The answer is neither yes nor no, but instead depends on the importance of the goal itself and the cost of failure.  To put it another way, execution goes a long way but without the guidance to know where you're going you'll only get lost along the way.

Monday, March 10, 2014

Apple Did What?

Figure 1.  The iOS code exhibiting the SSL handshaking problem.
(Originally published on www.servicevirtualization.com)

As a veteran of the application development industry, I can share plenty of horror stories about things that just "went wrong," from a tape backup software vendor not having a backup of my hard drive and then having the hard drive fail after I left, to projects that were canned after being in development for four years without a single beta release.

During those 18 years, however, I can recall having to go through a very rigorous process while working on Wall Street whenever any code was considered a Release Candidate for production.  Essentially, any code to be rolled out to production had to pass a code review by your peers, and we all took delight in shooting down other members' code, all in the name of quality.  In one instance, a library of common routines that I created after refactoring a few of my own applications was stuck in repeated reviews for six months before it was finally approved (after many adjustments on my part).

So, it's with this hindsight that I look at the gaffe by Apple where SSL handshaking wasn't being properly validated (that ultimately resulted in iOS 7.0.6 being released during the end of February), and I marvel that this even happened in the first place. Essentially, a superfluous "goto" statement was left in the code, causing it to exit out of the validation routine prematurely.  The code in question is shown in Figure 1 (taken from the Wired UK article with indentation reformatted to better fit here).

Although static code analysis tools such as HP Fortify and CAST should have caught this immediately, this lends itself to a discussion on why establishing a discipline such as Service Virtualization is so important.  It has been discussed repeatedly how virtualization decreases as the software progresses to the right of the SDLC (i.e. closer to a production release), but things are slightly different in reality as illustrated in Figure 2.

In this diagram, you can see that there are actually two types of virtualization that are utilized in the process of writing a software application:

Intra-application virtualization is the exercise of developing virtual services for components that exist within your own application. This occurs because components upon which a developer is dependent do not exist due to code development prioritization that is based upon the priority of the underlying business requirements. However, these availability constraints eventually work themselves out and, as a result, the need to virtualize those other components is reduced to zero at some point.

Figure 2.  The two types of virtualization
Inter-application virtualization is much different due to the underlying need that it satisfies. Here, other applications with which your application interacts have independent release cycles, independent infrastructure requirements (i.e. not typically covered by your application's CapEx budget), etc. Most importantly, these factors typically require virtualization of those systems to occur up to the go live date.

(I realize these statements about the length of usage of virtualized services is not entirely accurate because there are legitimate situations where the end of virtualization may be extended or contracted.)

Regardless of the type of virtualization being used at any given time, virtual services are developed based on the flow of data between components as part of one or more transactions. This flow of data is independent of the code in that it is frequently "designed" in advance of any code being written.  As a result, the data reflects the desired end state of the application or, to put it another way, what would be observed "on the wire" if the code were 100 percent correct.

Furthermore, because virtual services are essentially data and little more than data, the set of responses that can be returned by a virtual service in response to any given transaction is fully within the control of the owner of those virtual services. This allows the consumer to more easily test negative cases such as boundary conditions, off by one errors, etc.

This brings us back to the Apple problem. As you know, SSL is a technology that is used to facilitate secure communications between multiple software entities. And while both endpoints could be within the same application, more frequently it is used in inter-application communication.

The point is that virtual services could have easily participated in the SSL handshaking instead of live code. (More importantly, that inter-application virtualization would have existed a lot longer during the SDLC as noted in Figure 2.) And, since virtual services are just data that can be modified to setup specific testing scenarios, it would have been trivial to reproduce the condition that resulted in the premature exit of the handshaking code in iOS 7.

Monday, March 3, 2014

WhatsApp, Revisited

While researching for my blog entry about the Facebook purchase of WhatsApp, I wanted to get the opinion of someone who has industry experience in this sort of thing.  So I reached out to my good friend and former colleague Mark Pilipczuk who is a marketing veteran with 25 years of experience and a former SVP at AOL.  My question to him was simple:  did the purchase make sense when taking the cost into consideration.  His answer is below.

"I haven't spent any real time thinking about whether the $19B was a good/bad/indifferent deal.  What I have been thinking about is the YouTube acquisition by Google a few years back. Many thought the purchase for $1.65B in stock was excessive, particularly for a startup that had no real revenue model and had some serious potential copyright issues. In fact certain three letter ISPs looked at YouTube a couple of times prior to that and couldn't make the math work for an acquisition.

What Google was betting on--it turned out correctly--was the explosion of interest in the sharing and mashing up of video content. Google wasn't paying for a certain number of MAUs
(Monthly Active Users. -Larry) or how that rate of increase might continue or accelerate. Instead, they were betting that the number of minutes of video uploaded was going to explode and that the consumption of those minutes would also explode, shifting attention (and therefore media dollars) away from TV to online.

I believe Facebook's purchase of WhatsApp makes sense in general for the following reasons:

  • Facebook "and..." Facebook is no longer the "one-stop-shop" for social networking. It's also not dying among teens, regardless of what you might see in the headlines. Rather people are tending to use multiple networks and applications, depending on their needs. The basic one is Facebook supplemented by something like Instagram, Snapchat, Vine, etc.
  • Social networking moves to mobile. With the greater capabilities of mobile phones, it's easier and more convenient to do almost everything from our phones. There's no need to go back to the desktop to accomplish too much creation and all the consumption can be done from the handset.
  • All time spent online moving to mobile. It's not just social networking moving online. It's all time online moving to mobile.
If you're Facebook, you'd like that second/third app to be in your family of brands. Even if you don't monetize WhatsApp and put ads on those screens, you can certainly use the data to monetize Facebook. Getting access to that transactional and behavioral data is a good thing as it keeps it in-house and eliminates the need to license the data separately.

I think of the acquisition in terms of getting access to lots of data and gaining share of handset, particularly among the 2nd/3rd app being used for social networking. With the acquisition, the Facebook social graph on users gets more robust.

I think we'll continue to see Facebook acquire fast-growing apps, even if they don't have revenue models for the foreseeable future.

Now is $19 billion a good price? Absolutely no idea and I honestly don't believe anybody who's trying to model it out has a clue. If you're trying to value it on a per-user basis, which implies that the acquisition has some expected break-even, you're missing an important thing. Facebook, much like Google, isn't beholden to Wall Street. Zuckerberg and other insiders have control of the company's voting shares. They are already fabulously wealthy and can afford to play the long game, much like Brin and Page at Google. They don't have to justify the purchase price to anybody else and, if other shareholders don't like it, there's nothing they can do except sell the stock.

I think that for sure we'll look back and think tactically this was a good purchase. We may have a different opinion on the price, but I think that like the YouTube purchase, it'll be a few years before the jury returns.

Thanks for the amazing insight, Mark.