Nutanix - Stop the presses !!!

Ang79 just posted a very important post (#40716) which may get lost on another thread. RBC Capital, which co-sponsored the Nutanix IPO, says they spoke to management and found that Bloomberg was wrong, and that there will be no delay. A huge thanks to him for finding it.

…No change to expected timing of Xi Cloud Services launch

Contrary to a report by Bloomberg, we don’t believe there is a change to the expected launch of Xi Cloud Services

What’s changed: On Friday afternoon, Bloomberg reported that Nutanix might delay the launch of Xi Cloud Services due to engineering issues and the complexity of the service. Following the report, shares of NTNX closed down nearly 5% on the day.

What’s our take: We had a chance to catch up with management and believe that while there is a lot of complex engineering with the new set of services, there is no change to the launch of Xi Cloud from what was discussed at the company’s March 12th analyst day. At that event, management indicated that the plan was for early customer trials of Xi Cloud in the summer of 2018 and, based on that, making it available to additional customers in the second half of the year. We think the confusion was based on the original timing of Xi Cloud when it was announced at .Next in June 2017. At the time, management indicated that the Disaster Recovery Xi Cloud Service would be available in early 2018. Again, we think the launch of Xi Cloud is progressing as planned and we would expect to hear more when the company reports Q3/18 results in late May…


Fred Brooks wrote a slim book published in 1975 titled The Mythical Man Month. Fred was the IBM project manager in charge of the development of OS360, the operating system for Big Blue’s big machine of the day. The OS360 project was probably the most complicated software development project of its day. Fred’s little book described how standard project management methods were ineffective and at times counterproductive when the engineering project was predominantly the creation of intellectual property.

If you’re building a bridge and you run into a schedule problem you can generally put more manpower on the effort in order to meet the schedule. With a s/w development project adding additional manpower late in the project will more likely slow things down rather than speed things up, hence the title of the book.

Interesting little book. Still relevant today I believe.


Fred Brooks wrote a slim book published in 1975 titled The Mythical Man Month.

My favorite quote from the book:

“The bearing of a child takes nine months, no matter how many women are assigned.”

The Mythical Man Month was the software project management bible of its day (I have three copies!) but things have changed radically since then, not all for the better. Software now runs on a much more complex infrastructure. Back then it ran on your computer, now it runs on a world wide network more often that not written in multiple languages. This web page is running at a minimum on HTML, CSS, JS, and some server based language on a variety of browsers that are more or less compliant with standards and on a variety of devices with wildly different available screen real estate and input methods. No matter what the configuration, users expect satisfaction. In such an environment predicting launch date is close to impossible and expediency requires launching whatever you have working well enough.

The “Agile Manifesto” recognized this problem and proposed an incremental development method:

Manifesto for Agile Software Development

Denny Schlesinger


We could go back and forth, mostly corroborating one another regarding the pitfalls of s/w development projects. And especially how they defy the conventional wisdom of project management. There have been numerous stabs at understanding and harnessing projects. For a period in my career I was the manager of methods and tools for a very large application development community.

I only mentioned Fred’s book as a means of shedding some light on how difficult it is to predict the delivery date of a complex s/w development project months or years in advance. If the date is sacrosanct and the product is not ready the developer has but three choices: 1) delay delivery (this is usually not a choice), 2) deliver an incomplete, but hopefully useable release, and 3) deliver a buggy product and let the user community identify what must be fixed.

Larry Ellison was a master of option 3. Each new release of Oracle used to repair most of the bugs found in the previous release while simultaneously introducing a host of new bugs. At least, the DBAs in my shop held this to be true.

But I’ll end it there - just too far OT for this thread.


Agile is the way to go. Release something often rather than everything rarely.