Promotion, pyVmomi & future updates

I was recently promoted at VMware and I have new duties. The new day job (as I lovingly call it) is taking a great deal of time that I would normally devote to side projects like pyVmomi. I am hoping we will be able to find others inside VMware that I can delegate duties to.

In the mean time, I'm unable to predict project velocity because I'm unable to predict how much focus I can direct at the project. My next major action on the project will be to attempt to release an alpha release of pyVmomi with some spot-fixes embedded.

When I have a few hours to steal away for this I'll post here and talk about how to get this version and a disclaimer that the release is alpha quality and may put your own systems at risk should you use it. However, I also want to put something into user and administrator hands sooner rather than later.

Thanks to the community for continuing on as I'm working heads down.


Return on Investment: high, low, and durability.

I'm heads down focusing on delivering a critical new feature to another team. But, I wanted to stop a moment and mention some of what drives how I prioritize things, how on occasion I'm directed privately to deprioritize some tasks that were very high priority previously and what the thought process behind these choices are.

We all have 24 hours in a day and 7 days in a week. Studies show that from a pure numerical stand point working more hours beyond a certain point produces a net loss in output. That is to say, plugging away at a job beyond a certain point produces a net negative return due to increased defects, mistakes, and general fatigue and a phenomena we call burnout.

Part of your own self-management should be guarding against burnout and working for net-positive output. The other part of this is to ensure that you are working in an area that will yield the best return for your personal investment. In this case, I'm talking about choosing a project and place to sink your time and effort.

Classical Prioritizing

We take a project and walk it through our decision making process then, we prioritize it based on its return on investment. Most folks are familiar with this decision making grid:

Source: http://www.ashpfoundation.org/leadershipprimer/Primer19.html (which I thought had nice graphics but don't necessarily endorse)
... in which we make sure we keep doing the things that are important and never allow ourselves to dig into the unimportant and never urgent things.

I'm going to tell you that this particular grid is a great idea for business people in general. But we are not business people. We're innovators by definition. For us there's one more dimension that should influence our decision making.

Durability and priority

As an engineer, software developer, or innovator your job isn't merely to do your job. Your job is also to invent the future. That means if you are forever under the tyranny of the present you'll never get around to inventing the future. You absolutely must make room to invest part of your time into things that seem like a waste of time now on that 2D chart but will make more time later.

For example:
  • automation
  • invention
  • mentoring
If it is repetitious, it is in a computer or involves a computer, and it is well understood... why isn't it automated? If you answer "because I don't have time" then take a moment to calculate the total time you and/or your colleges will spend doing this task over the total projected life-span of the technology stack. Then calculate a rough order-of-magnitude estimate of how long it will take to automate the task. If the two number are at all close you should automate. That's because even if you personally don't create the automation there's a high probability one of your less experienced peers might be able to use the project as a learning tool allowing you to mentor them into a higher level of proficiency. This process in turn leads to invention and innovation of the problem space.

This is the property of durability of an investment. It may be a low yield on the traditional return on investment style calculation you might perform but sometimes these apparent time-sinks when used properly enable a long term durable return. 

That automation that took 3 months to invent and deliver (delaying another project like pyVmomi for example) will eventually yield a savings of 5 minutes a day over 300 engineers or a dividend of something in the neighborhood of 375,000 engineer minutes over a year. Break it down another way and you could call it 375,000 minutes (divided by 60 minutes in an hour & 8 hours in a work day & 4 work weeks per month) = 195 mythical man-months or in other words, delay now and save a whole year of effort over the next decade. 

Is it worth the trade? Keeping in mind that having a wonderful 10 year plan does you no good if you're dead in the water tomorrow. So we do still have to consider the classical decision making matrix but we should also pull our 3rd dimension of durability into consideration when two opportunities look the same otherwise the more durable investment of energy should win since it will pay us back for longer.

The next question is whether you should do the task or if you should delegate the task. This is a slightly different set of calculations. We've established that the task (whatever it is) should be automated, just not precisely how. That's highly dependent on what resources you have available for performing the separate tasks of inventing the automations you need to eliminate the initial task we were considering. If the personal savings exceeds the personal expense then you should definitely perform the automation. If the group savings exceeds the group expense then the group should have someone perform the automation.  Incidentally, when the personal benefit doesn't match the group benefit, we've got the potential for conflict.

At the moment I'm personally pinned working on only the #1 quadrant of important and urgent.

More on this later as I get more room to delegate.


How to make a choice

Today's post is just general life philosophy. Nothing technical, and just some fatherly advice of the kind I might pass to my sons. Here's a simple set of things I ask myself before I choose to invest myself personally in something. This came up because my eldest son is working on his college career and making hard choices about what classes he'll take and which jobs he'll work.

These days I follow this process instinctively. I don't consciously think about it. I do this in everything from marriage to Open Source projects. And, when there's a crisis or decision to make I will stop and work through this set of questions again. That's because things change and sometimes we have to as well in response. It's advice, take it or leave it. I think it probably applies to relationships just as well, but I'll focus on career choices for the sake of clarity and brevity.

Will it work?

The first step to evaluating whether or not to invest yourself in a project, a technology stack, a start-up, or a community is to really honestly ask yourself if this hare-brained thing will actually work. When I interview for a job, talk to start-up founders, or even projects at big multi-national multi-billion dollar corporations I ask: will this actually work? If everything is perfect but the core idea is completely unworkable it's time to move on, no other factors (like love or money) will really matter.

It's hilarious to me that so many people trying to convince me to spend my blood, sweat, tears, and years on their project don't bother to explain to me wether their wonderful idea is going to work or not. There's usually a two sided argument to this first part of my decision making process. It's got to be a dance. The first side of the dance is the optimistic side that believes the idea, the other side is the pessimistic side that doubts. For me, I need to see that both sides have played a part in the dance. If I see only one side entertained, I'm likely to leave feeling that I've been deceived at some point. That sense of deception will likely make things unworkable later.

On the other hand, if you dwell only on the pessimistic reasons something won't work, you'll never entertain any new ideas. I was all pessimism when I reviewed Netflix in the early 2000's. I had been solicited by someone (I forget who) before Netflix's IPO and I didn't follow through on pursuing the job because all I could think of were the reasons Netflix would fail. I was terribly wrong. They succeeded wonderfully but I couldn't see how at the time, and that's a bit of a shame.

These same instincts also prevented me from taking jobs at companies that really were truly total disasters. There's a few dozen risky moves I could have taken that I won't bother listing that really would have tanked my career. So, there's a careful balance, a dance or courtship with a new idea. You have to allow for the good and account for the bad. You can't be terribly precise at this phase, but you should at least stop and evaluate in dispassionate isolation the idea first.

If you don't have the tools to answer this question, you might have to just own that inability and decide whether you're an optimist or a pessimist. Now, you're just going with your gut. At least know that's what you're doing. It's practically a defining trait of being human, we don't know things and sometimes we jump without knowing. Know that you don't know and that you're taking a leap of faith.

Answer this question from all the wisdom you have, not bravado, not fear.

Can you do it?

Just because an idea will work, it doesn't mean you personally can make it work. You may not have the skills, training, or talent to make a good idea actually fly. There are plenty of wonderful ideas and opportunities in the world but if it requires a skill that you can't possibly gain there's no point in pursuing it.

In some ways, this question too comes down to being wise enough to balance bravado and fear. You are a quantifiable value to yourself. You should have done some work already in this area. Sometimes this is learning to do something a bit scary or a bit hard for you and seeing how you overcome obstacles and what trips you up.

Are you bad at math? Is math going to be key to making this idea work? Are you bad at working with people? Is this idea going to sink or swim based on people-skills? You need to have as accurate a picture as you can of what you do well and play to your strengths.

That doesn't mean you have to carry the whole project, idea, relationship, community, or whatever it is all by your lonesome. You'll hopefully have a group of others along with you for this experience. You'll need to assess whether you and that group can work together, overcome together, and if the group of you have the right skills, in the right place, and at the right time to actually pull this thing off.

Answer this question from a deep understanding of yourself and your partners in this enterprise. You don't have to be able to do it all right now, you just have to be able to grow into it. You may have to continually evaluate and adjust this part as things change.

Is it worth it?

Since, I've already mentioned Netflix, I'll mention them again. The second time I talked to Netflix was post IPO. I had a son in High School and even though I think we all thought I was a good "fit" for Netflix at the time, I wasn't prepared to sacrifice his high school and potentially college experience for my personal career satisfaction. To me, my son's continuity of community was more valuable than the amazing opportunity Netflix was potentially offering me. Part of me is wistful about that choice, but I made it knowing that my sons are the most valuable thing in the world to me and I was sacrificing for them. When I look back at it in that light I'm actually proud of the choice I made even though a potentially great future died because of it.

Most of the people I've known are great at sacrificing profoundly for something they really believed was worth it. I save this for last because it's too easy to answer blindly. A great idea might self-evidently work and the reward for making it work might ostensibly be worth it ... "we'll be rich!" ... "we'll be famous!" ... some move or sacrifice might seem worth it when viewed in isolation. The trick is, you never get to do anything in isolation.

You are always going to be you. You will always care the most about the things that you care the most about. If you don't count those things up first before you ask "is it worth it?" then you don't really know what you're selling to be able to buy this shiny new thing. I personally believe this is the source of many people's regret. They chose without knowing what it was they were doing and ended up giving up something they, in their inner most core, thought was more valuable for something that was simply not worth the thing that they exchanged.

I've known women that sacrificed family for career. I've known men who have sacrificed career for family. These people are happy or depressed depending on whether they understood the value of these trades and whether they chose the thing that was truly the most valuable to them. For some, children are worth more than billions of dollars and a place in history, for others a place in history is worth more than any personal comfort. Which are you? Which are you really? These things change.

The final question of what is worth your sacrifice relies on having answered the other two well and on knowing yourself well. If you know the idea works and you work with the idea... when all is said and done, will you be proud or ashamed of the sacrifices you made? Choose well, you can't know the end from the beginning.

Will you be proud to have failed at this?


If you're into this sort of thing, my three questions are based on the parables from Luke 14:25 to 15:32 just dressed in modern clothes and removed from the period language and concepts. It's not a complicated set of ideas. I'm sure other faiths have similar teachings, but I don't know enough other scriptures to tie them in I would love to hear other faith's teachings on this topic. 

These parables in particular are about being human, making choices, and living with the consequences. They're valuable in practical ways for making us think about what we're doing and how we're living. As a collection of teachings they're an invitation to live deliberately wether or not you ascribe supernatural meanings to them.

Another analogy I've invented for this particular lesson is:
Imagine you are old and spent. There's a child you care about. You can't lie to them. You have to tell them your life's story. What will you tell them about this moment? What will you tell them you gave up? What will you tell them you chased after? Was it worth it?
Knowing that you can't tell if you'll win or lose yet, you have to be comfortable discussing the loss. Live deliberately, not accidentally. Choose well, and live well.


pyVmomi and VMware’s internal R&D Innovation Offsite for 2015

I've been invited to speak at VMware’s internal R&D Innovation Offsite (RADIO) on the topic of my experiences with pyVmomi. This is a rare honor, and I'm very pleased even just to be invited. For the pyVmomi community this potentially is a big boost to our visibility.

I expect to be sharing the stage with some heavy hitting presenters with big ideas to share in a fast-paced TED Talk like format. So, I'm spending a good deal of effort making sure I make the most of the opportunity.

I only have so many hours in a work week. That extra effort in one area means other areas slow down a bit. For you, that translates into a bit less predictability in when things are going to happen on pyVmomi in the near term. Right now, the plan of action looks something like this:
  • Roll out a beta of v5.5.0.2015.1 by the end of Q2 2015 as a bug fix only release
  • Begin alpha work of v6.0.0.2015.2 for alpha release by the end of Q3 2015
The links above are to the issue tracker for issues targeted to their respective releases and these lists may change in real time as the community works through the release. Naturally, these are aspirational statements at the moment so the plan may have to change as we roll forward. But, I think this flexibility is the strength of our process on this project.

I have also resolved to spend more time mentoring new developers. That kind of work may cut into my actual code output and slow things down a bit when it comes to things that I personally code. The return for that slow down will be that we will grow a larger core group of developers who will be highly skilled and capable of executing projects like this one in the broader community. That's something the world just needs more of in general, so I think it's a good investment.

In a nutshell in 2015, I want to focus on mentoring more developers who can help drive this type of work forward. If you want to help and don't know how to get started, reach out to me and I'll do my best to connect you to the right places depending on your skill level. If you just want to start cutting code, feel free to jump into the samples project and start slinging away.

Either way, welcome to the party... it's just getting started.


retrospective and prospectives

You're busy, I'm busy, so here's a Summary of the post's points.
  • I'm focusing on pyVmomi for a Q2 release (hopefully earlier)
  • I'll be assisting in on boarding rbVmomi contributors from inside VMware in Q2 (I hope, no solid commitments there yet.)
  • Both rbVmomi and pyVmomi will have samples of the vSphere 6.0 API some time in 2015


If we look back at the amazing output we saw in 2014, it was driven by a clear targeted focus. We knew that pyVmomi needed to be future proof. It had to be able to survive into the Python 3 era. A quick survey of the pyVmomi code base reveals that the project has existed since 2008. (I've personally been doing integrations with vSphere on some level since that time without knowledge that pyVmomi existed.) This was a big step for VMware to Open Source the project.

Today pyVmomi is a fork of that internal project. The idea of a vibrant and collaborative Open Source community improving vSphere is a novel idea. It's one that I hope will catch on. That said, 2008 was a long time ago in internet time. The future is coming and it's called vSphere 6.0

Much of this goes for rbVmomi too. I have a mental cycle that I use when approaching a project. When I enter a new project there is always a period of observation and orientation before I make decisions and start acting. When my attention is divided that forces me to lengthen my input phase before I make a decision and then act.

On the pyVmomi project I've come to trust the judgement of a select handful of contributors. If they like the submission I'm more likely to accept it. I've not built relationships like that on rbVmomi. It takes time to form that kind of trust and I'm actively soliciting VMware staff who are deeply experienced Rubyists for help in forming those.


Most VMware followers will know the company had a big launch in February. Some of what I've been doing is coming along side folks who needed a fresh pair of eyes just before release. The launch of vSphere 6.0 is a big step toward a new future for VMware. There are many new features and new ways to integrate, converge, and innovate with these offerings. The new vSphere 6.0 API collectively point the way to how VMware of the future will deliver API, I am eager to hear people's reactions and to help adjust these offerings.

I'm currently juggling pyVmomi, rbVmomi, and a separate academic research project that I made commitments to. I've been talking to folks about delegating some of this work. Each of these projects deserves my full attention right now, but I can only divide myself so much. In the case of pyVmomi and rbVmomi your participation is vital and I view my job in this area as supporting the community's desire to get things done on vSphere.

I'm not the primary mover here, you are. That includes work on getting pyVmomi into the hands of python developers however they manage libraries. That is all work initiated by and driven by folks like you. As I dig deeper into what needs to happen in 2015, I would welcome your participation. If you want to take on one of the fixes that need to happen, let me know via GitHub or via IRC.

I've also gotten an early look at the vSphere 6.0 SDK and I know that there are a few new API features that developers will find immensely useful. There is also a grand SDK vision to be worked out and its early days to be talking about that yet. Remember that pyVmomi is currently a Fling from VMware so it's living in slightly different product support space than most VMware products do.

Project Goals

Both rbVmomi and pyVmomi will have code samples available that will show off the new vSphere 6.0 API and I can talk about that more as we come up on the release. In the mean time I'll be firming up what we're going to deliver in our rapid succession 1st and 2nd releases of 2015.


Projects status for Q4 2014

I'm presently allocated to several other vmware projects that are running up against hard deadlines in January 2015. Because of these resource constraints, I've been forced to remove the time lines from my other projects including the public GitHub facing projects. Both pyVmomi and rbVmomi presently do not have time lines for release anymore. I can't control my velocity on these projects, therefore I can't reliably forecast release time lines.

I will revisit both pyVmomi and rbVmomi in February of 2015 and update the projects respective time lines when I gain clarity on what can be done and how long it will take.

It is important to note that these particular versions of these projects are not officially supported VMware products and do not have purchasable support plans at this time.  I will continue advocating inside VMware for the inclusion of these Open Source projects as part of the over-all product suite and API plans, however, at the moment these are Flings under the VMware labs umbrella.

I have truly relished working on pyVmomi in this very open manner and I'm actively looking for ways to make the best parts of this project parts of every project that I work on. I have already presented to various groups the wonderful lessons we've learned from both pyVmomi and rbVmomi. I feel some of my audiences were truly enlightened by my frank assessments of the lives of both these projects.

That reaction to these experiments encourages me in my pursuit of finding better ways to make impactful software. What every developer should be after is impact, not volume. We should pursue not creating more code, nor more refined code, but creating code that makes a bigger impact with lesser effort. By the term 'impact' I mean various permutations of the words 'useful', 'efficient', 'important', 'delightful', and 'powerful'.

I will post more updates in the first three months of 2015 as I have them. Progress will be quite slow between now and then as I will have to address a number of other duties and deadlines. Happy New Year to you all and I look forward to getting back down to business in 2015.


This week on pyVmomi/rbVmomi

Last week, I took on a high priority task for VMware so my work on pyVmomi and rbVmomi had to move down in priority for me. I'll continue to post regular updates on progress but the velocity will have slowed on both project until I have cleared my higher priority tasks.


  • I have slid out the next release until November 15th
  • I have begun learning how to upstream the github changes into the VMware git repos for rbVmomi
    • we will need to determine the upstreaming process' impact on the public repo
    • I need to get any merge requests peer reviewed by VMware internal folks before proceeding


  • I have triaged 2 new bugs
    • issue 176 is an interesting issue we've seen directly impact integrations like OpenStack, SaltStack, and Ansible. I would like to find a clean answer.
    • issue 180 is a problem I've heard reported before, it has to do with a newer vCenter server speaking to an older ESXi host. The current work-around is to ask the programmer to select a lowest acceptable version number (ie: 5.1) and use that namespace exclusively. The bug reporter has done a good job of breaking down the problem. We need to have a solution that will work robustly and impact client code minimally. EDIT: This issue is only known to impact ESXCLI use at this time
  • I wrote a simple sample for an IRC user today describing how to navigate a virtual machine's hardware devices. The sample is rather straight forward and I was glad to get to write a sample after having neglecting samples for so long
  • I  revisited pyVmomi-tools and started a testing refactor using VCRpy

Thursdays will be my rbVmomi/pyVmomi day and I'll alternate between the projects. This week I spent most of my time on pyVmomi so next week I'll try to focus on rbVmomi.

More next week...