wrong tool

You are finite. Zathras is finite. This is wrong tool.

Hello Michael!

by Leave a Comment

  
30 years ago I remember reading about Dell Computers and wanting one very badly.

Living in Greece, Dell computers were these awesome magical things that you could never own. 

When I came to the USA in 1992 to study at Brown University I couldn’t wait to buy a Dell. My first Dell was bought in 1992. That Dell never stopped working.

Apparently neither has this one. 

And so I know it’s just a side effect of some social media person filling out some form and cross checking VP’s at VMware with his LinkedIn profile and I know it’s nothing personal… And I still think it’s cool!

The Roach Motel known as Some Unicorns

by 4 Comments

Growing up, one of my favorite positioning of products was the Roach Motel, a cockroach trap.

The trap used a scent to lure the cockroach into the trap and then used poison bait to kill the pest.

The Roach Motel entered the vernacular through their clever slogan:

Roaches check in, but they don’t check out!

Turns out Unicorns with cleverly structured stock compensation programs are no better than The Roach Motel for employees that join.

Let’s be concrete.

If you join VMware, the minute you vest your shares there is a large public liquid market that you can turn those shares into cash. There are no restrictions on how many shares you can sell. The only restriction on selling them is if you have material information that makes you an insider.

If you join a startup, the shares are vested, and you can’t sell a single share until some liquidity event happens.

No problem, you think to yourself. I will just wait until the company IPO…

But what if you have to quit your job?

Well then that’s okay, you can just …

Um.

There are two options

(1)  If they are options you just buy them and take them with you. Except you may not have a large pile of cash that you can use to buy them with. And unless you made money at your last startup you probably don’t have that kind of money. And so you lose them.

Except that some stock plans may not give you that option. Because they don’t want anyone to own the shares outright until after a liquidity event that is not an employee of the company or a direct investor.

Even if you, had the cash, you may not be able to.

Well it’s a litle more nuanced. You do have the right to buy the shares, and then the company has the right to buy them back from you when you are leaving at what they think is the fair market value.

See what happened to Skype employees. http://techcrunch.com/2011/06/26/skypes-worthless-employee-stock-option-plan-heres-why-they-did-it/

This kind of behavior is not as uncommon as you think.

(2) I will take my RSU’s and run!

Again companies can do the same thing…. You get your RSU’s and if you leave the company you lose them. More precisely they get sold back to the company at the price the company decides.

So what to do?

The short version, is that don’t assume your equity in a Unicorn is yours. Make sure you get a lawyer or a person in HR that doesn’t work at the company to walk you through the agreement for any specific time bombs.

And remember rules can change capriciously later.

For Valley employees, Unicorns with their ever receding IPO dates, their preferential treatment of founders and early investors are increasingly looking like a Roach Motel where employees can join with the promise of future fortune where none is to be found.

 

 

 

What is technology leadership and management

by Leave a Comment

In my last couple of jobs, I’ve had to define technology leadership. And, in particular, how it relates to code.

The motivation in one job was that the engineers and management had passed the accountability buck to the process. The motivation in another job was to codify well-understood practices.

Each slide deck was different. And had specifics, and so I can’t share the deck’s as is, and I figured other people might be interested to know how I think about it.

When working on accountability and responsibility, the first problem is defining the terms. Here’s the definition I used that I borrowed heavily from several RACI websites.

2015-11-20_1500

To me, the fundamental intuition is that the accountable party makes the call, and the responsible party owns making sure that it’s the right call.

The next question is, what is technology leadership, and why is it important.

2015-11-20_1505

The key points are that technology leadership is about building great products, and great products are a function of product management, great technologies, great teams, and great sales and that technology leaders are responsible for all of those.

One thing that gets lost in discussions about technology leadership is the role of management. Managers are a vital player in this party. And in many ways, I view managers and technology leaders as separate actors.

2015-11-20_1512

You’ll notice managers are accountable for planning and team quality and execution, and technology leaders are accountable for technology and quality and the quality of the artifacts produced. And they are, in turn, responsible for what the other guys are accountable for.

If your technology leader and manager are the same, my experience is that you either get a better quality product with missed dates or get worse quality on time.

And this creates tension, especially on the dates.

2015-11-20_1518

The point is that the technology leader and manager should not see this tension as a winner takes all battle, and instead view this as a conflict whose purpose is to force a compromise that delights the customer.  A poorly architected product is as big a failure but that ships on time is as big a failure as well-architected product that ships late.

 

2015-11-20_1519

And the conflict is desired. It’s not an accident. You create the tension to force the compromise. And the compromise is a good thing if it produces an outcome that is aligned with delighting our customers.

Going to work for SpaceX … No, not really.

by Leave a Comment

Four years ago, Andy Van Dam let me give a small talk to his CS 15 class. I stood in the auditorium, in front of 200+ students, and had a momentary epiphany.

I told the class:

You are the luckiest people on the face of the earth. When I started my career, working on computers meant building systems for banks, or weapons to kill. Software has now become embedded in every aspect of our lives. Everything you want to do has a software angle. You can save the world, or build a weapon, or save a child and still work on software. You can follow your passion and dream and work on software. And I am envious of you.

I think I said it better than Andreesen. But I am not a venture capitalist and the inventor of the web browser.

The point is that if you want to write software for a living you can do anything you want.

My son keeps asking, what do you do for a living daddy? And I keep trying to explain software. Try getting a child to understand what writing software is.

Every night, I read a book to my son. And today we read about the Curiosity rover. And I remembered that Jim Kurien, an old Brown University friend, had written software for that program.

And my wife said:

See, Nicholas if you write software you can work on robots that go to Mars.

And my son full of awe and admiration and eyes bigger than saucers asked:

Daddy, Daddy, do you work on robots?

For a moment, I was his hero and cool. My work wasn’t something that took me away from him, my work was something special. Software was special. The lightbulb of why I did what I did went on.

And I said:

No.

And my son looked as if I was the dumbest man on earth. Because if I could work on robots, why would I not be …

And then I turned to my wife and said:

I hope you like LA. You know, the headquarters of SpaceX.

All humor aside, I am happy with my job, and I love the problem I am working on, creating a unified virtualized hybrid infrastructure. Not as sexy as the Curiosity Rover, and probably not as transformative and just as exciting to me.

And hopefully, my son will learn that lesson in life. That what is interesting to you is all that matters.

 

Scaling efficiently instead of scaling up or out.

by 1 Comment

Over the last few months, I’ve been involved in a lot of discussions about how to make software systems more efficient.

When we look at making software go faster, there are three basic approaches

  1. Pick a better algorithm
  2. Rearchitect software to take advantage of hardware
  3. Write more efficient software.

From about 1974 when Intel introduce the original 8080, up until 2004, conventional wisdom was that writing more efficient software was a losing proposition. By the time the more efficient software was written, Intel’s next generation processor would be released improving your code’s performance. The time you spent on making your software go faster, represented a lost opportunity to add features.

As a result, a generation of software engineers was taught of the evil of premature optimization.

Textbooks, and teachers routinely admonished their students to write correct code, and not efficient and correct code.

Starting in 2005 with the shift to multi-core processors making software go fast was about taking advantage of multiple cores.

Software developers had to adapt their systems to be multi-threaded.

At the same time, software developers noticed that the number of cores per system was limited and to get ever increasing scale, they had to be able to leverage multiple systems.

And thus the era of scale out distributed architectures began.

In this era, software engineers had to create new algorithms and new software architectures, and writing efficient code was still not viewed as an important part of delivering ever faster software.

See from 1974 to 2015, the name of the game was to use more and more hardware to make your software go faster without any consideration to how efficient the software is. From 1974 to 2004, you just waited for the next processor. From 2004 to 2015 you re-architected your software to take advantage of more cores and then later to scale out to more systems.

And by 2012, writing large scale distributed systems was easy. A combination of established frameworks and patterns made it easy to build a system that scaled to hundreds of systems.

Software engineering had discovered the magic elixir to ever increasing performance. We could harness an increasingly large number of systems combined with multi-threaded code to get infinite performance.

If the 1975-2004 era made writing efficient code of dubious value, the scale-out age made it even more questionable because you could just add more systems to improve performance.

High-level languages, coupled with clever system architectures could make anyone deliver an application at scale with minimal effort.

Was this the end of history?

No.

It turns out that large scale-out systems are expensive. Much like processors hit a power wall, massive data centers that consume huge amounts of energy are expensive. And companies started to wonder how do I reduce the power bill?

And the answer was to make the code go more efficiently. And we saw things like Hip-hop emerge, and Rust. Hip-hop tried to optimize code. Rust tries to provide a better language for writing efficient code. And in parallel we see programming languages like Node.js and Go become popular because they allow for more efficient code.

Software efficiency has become valuable again. The third pillar of software performance after a 40-year wait is the belle of the ball.

And what is interesting is that the software systems of the last 40 years are ridiculously inefficient. Software engineers assumed hardware was free. And because software engineers made that assumption, large chunks of software are very inefficient.

The challenge facing our industry is that to improve the efficiency of software we will either have to rewrite the software or figure out how to automatically improve performance without relying on hardware. No white knight is coming to save us.

And we are now looking at the world where performance and scale are not just going to be a function of the algorithms, and the architectures, but of the constants. And in this brave new world, writing efficient and correct code will be the name of the game.

We will not only have to scale out and up, we will also have to do so efficiently.

Put differently, perhaps there is no longer such a thing as a premature optimization?

 

 

 

Square fails

by Leave a Comment

First of all congratulations to the square team for getting to an IPO.

https://recode.net/2015/11/06/square-takes-an-ipo-bullet-for-all-of-the-overpriced-unicorns/

Not so good news for employees whose equity is worth about 1/3 less… The number was pure fiction before and at least now it’s a real bumber.

Unicorns the latest technology for taking money from the working stiff!

Thank you Scott!

by 1 Comment

Whe I started my career, my first boss on my first day told another engineer:

Are you doing anything useful or are you just breathing my air?

He then later turned to me and informed me that there was this five year rule. And I asked what is the five year rule?

And he said:

You keep your mouth shut for five years.

And so I learned to model that behavior. I thought being a technology leader meant being a dick.

And then I met Scott Schoenthal at NetApp and learned that you could be a polite civil and compassionate leader. That being nice was a better way to lead. That ripping people to shreds, publicly shaming them, calling them names wasn’t the only way you could get your point across.

I didn’t always model my behavior after Scott – Lord knows how many rants I produced in this life …but I am glad I learned about that other way to lead.

As an engineer it’s easy to see the cantankerous asshole email and say: I want to the guy who writes that email. Writing that email means you arrived. It means you are the man.

Except it doesn’t. It means you are an asshole. You are reveling in your ability to abuse someone who is defenseless. You are modeling poor behavior.

Just Don’t Do It.

Scott Schoenthal was the first person to show me another way….

How Stanford Screws the Middle Class

by 3 Comments

One of my personal enduring mysteries was why do the top 100 private colleges charge about the same amount of money for tuition.

Given their wide variance in size, location, and endowments, you would expect to see a wide variance in price.

Except you don’t. The list price for a college education is about the same.

And then I spoke to someone who is deep in the bowels of Stanford’s budget and figured out how exactly Stanford is screwing the middle class.

Let’s begin with the following startling observation. Stanford has two sources of revenue. The first is a draw on their endowment. The second is their ability to issue bonds to borrow to build (check out http://bondholder-information.stanford.edu/home.html)  Tuition, is a drop in the proverbial budget, a rounding error.

Just to make it real, the draw on endowment is about 5% a year so

21.4 billion * 5% = 1.07 billion

Student tuition = 14k * 3 quarters * 7k = 294 million

Ah you say, look! it’s 30% of the budget… except. about 4679 get some kind of tuition reduction, so let’s cut that number in half so it’s about 150 million dollars or about 15% … A drop in the proverbial bucket in a billion dollar budget.

Let me think about this for a moment. Stanford benefits from tax exemptions from gifts and simultaneously benefits from tax benefits while borrowing money while demanding money it doesn’t need from parents after tax income.

Hmm…

Let me repeat, the tuition that basically destroys a college graduate’s ability to buy a house or devastates a parents retirement is a rounding error in Stanford’s budget and comes from your taxable income.

Is this about Stanford? Certainly not, it’s about Harvard and Yale and Brown and by implication every institution of higher learning that is charging more money because they can.

Why does your college education destroy your life and your parents retirement? Because we’re stupid enough to pay for it.

 

Apple v Google – c’est la guerre

by Leave a Comment

Just before Greece and Italy went to war, the Italian Ambassador came to General Metaxas and told him the terms for peace. Metaxas apparently replied in French that they both spoke: ‘Alors c’est la guerre.’

What had happened was that the irreconcilable differences between the two great nations created war. The goals of the Fascist Italian leadership and the national goals of Metaxas made war. And this in spite of the ideological alignment between the two leaders. Mussolini and Metaxas were both fascists.

Apple’s decision to create ad blockers was inevitable. Apple is primarily aligned with the folks who buy their devices. They are absolutely committed to building a compelling experience on their platform at the expense of everyone on their platform. Customers pay for the platform and Apple’s biggest source of revenue is that platform. That single-minded focus on the platform experience had to lead to ad-blocking because ads are the single biggest source of irritation in the web-ecosystem.

Google because it was aligned to maximizing ad revenues and not maximizing the web-ecosystem experience, left Google vulnerable and by extension the web vulnerable to Apple’s decision.

Google had about 15 years to make the web better, instead they focused on extracting even better revenues from the web through more efficient ad-revenues. Google never took ownership of the web-platform. It’s unclear that Google could have taken ownership or stewardship. Because Google didn’t own the platform.

This outcome, the  assault on the ad system that powers the web to the detriment of the user experience was inevitable. The only option is for Google and the ad networks it supports to figure out how to make ad’s better.

 

Packet re-ordering is bad.

by Leave a Comment

One of the weirdest things at Juniper was the obsession the networking teams had about reordering packets. They kept talking about how applications could not tolerate reordering.

And this confused me to no end.

After all TCP was based on the assumption of packets being reordered and out-of-sequence and surviving that mess?

And then it was explained to me as if I was the networking NOOB that I am. The problem is that when a packet gets reordered TCP doesn’t perform as well as when the packet gets sent in order. And there are scenarios where TCP will assume that the network is congested if the packet doesn’t get sent in time and will slow down the network connection.

And so to work around the TCP protocol thinking it understands what is going on in the network, ASIC engineers do heroics to ensure that packets flow through routers in order.

Then I read this today and I was reminded of those conversations:

http://gafferongames.com/2015/09/12/is-it-just-me-or-is-networking-really-hard/

There are all sorts of very interesting applications that run over the Internet that really are just pumping packets and want them arriving in order or not at all.

And that because of these applications the design complexity of routers is vastly more complex than if the layers above the network did not assume anything about a reordered packet.