Notes on "Navigating Corporate Giants: Jeffrey Snover and the Making of PowerShell"
Notes on Navigating Corporate Giants: Jeffrey Snover and the Making of PowerShell
This is an interview with Jeffrey Snover on how PowerShell was built and his experience of the roadblocks. And man, there were roadblocks.
This is a typical story I saw in many places: the engineer wants to do the right thing, the corporation pushes back, the engineer perseveres and finally emerges victorious.
The hierarchy changed suddenly:
There’s been a reorganization and, and, and you’re not going to be reporting to me. You’re going to be reporting to this other person.
He got demoted:
And basically the answer was, ‘Well, okay, we’ll let you work on it, but you know, you can’t keep that job.’ We’re going to take that away from you.
And so, yeah, so I got demoted.
Worked on a project that does not get you promoted:
You know, at Microsoft, everybody’s hair’s on fire and they have 10 jobs and they got to decide which nine they’re going to fail and not, not get fired. Right? And the command line interface is something that, Not doing it would not get you fired
and doing it wasn’t going to get you promoted.
Office politics:
Even though the project survived, it had funding, it was still not part of Windows. It needed a way to get back in. ... ... Like 20 minutes later, the executive sends back mail saying, withdraw this request. Like the head of windows, withdraw this request.
Still no promotion:
I got to do the next version. Like, no, no, you’re a senior guy. You need to do something else. Otherwise, you’re going to get pigeonholed. And it’s like, no, I’m going to do this. And it’s like, well, it’s going to hurt your career. I say. Whatever. And so then that happened with version two, and then it happened with version three, and then it happened with version four,
But then there is the happy end:
So it took me five years, but I finally got my stripes back became Distinguished Engineer and then eventually Technical Fellow.
At some point I went to work in office and the head of the office, we were having lunch, and he said, “You know, you realize that PowerShell is the reason why Microsoft’s in the cloud.”
As I see, a story like this happens all the time. The tragedy is that probably most of the struggles end before the happy end: the corporate wins and the hero is ousted out of the job or had to give up.
The most interesting thing is that PowerShell was an already validated idea: unixes had scripting abilities for decades by that time. But it was still incredibly difficult to sell the idea:
But the software wasn’t as good, especially for managing many servers. You are physically clicking a mouse and configuring things on every machine and the setup you need for each business might vary.
A bank is different than an industrial control process, is different than a, you know, a scientific lab. Everybody’s different. And so basically, if the scenario doesn’t work, then what do you do? And the answer is IBM Professional Services.
So now all of a sudden, I say, ‘My hardware costs 10, my software costs 2, and then my systems integrator costs me 40.’
Solution: scripting. But still no:
And so their mindset was, well, no, that’s a bad idea, because it requires, you know, a smart admin to do something. Instead, tell us what the We’ll put it into our queue. We’ll spend a couple of years developing it. Then we’ll ship it as a new product. Then if and when they adopt the new product, problem solved.
It’s like, but immediately after you sell that product, the scenario changes. So we’ll then tell us again and the next version will include it. It’s like, you’re just not getting it.
And finally, this part on dysfunctional corporate processes resonated with me:
Well, it turned out when they said, “Our coding window is 10 weeks,” what they were doing was they’re just writing code for 10 weeks. And some of that code would be like a function. Uh, comment, fill in this function, check it in. And then, so you have 10 weeks worth of that. Then nothing works after those 10 weeks, nothing. And then they spend like a couple of years making it work. It’s like what the hell is that? ... ... after 10 weeks, you couldn’t do anything new, but you could fix the bug. The bug is doesn’t work. I mean, how crazy is that?
Yeah, I saw it myself: one time there was a system I needed to integrate with. The whole integration was simple: a couple of hundred lines of code on the other side, maybe a quarter on mine. But the protocol was flawed and I got onboard after it was implemented by the other side already.
So, I proposed a change to fix that: we're talking about maybe 2 hours of work for 1 engineer, and the fix was clearly better and wasn't contested by anyone.
What happened? There was a 2-hour long meeting with 3 people trying very hard to convince me that the fix is not needed. We were reading the specification line-by-line at one point. In the end, the fix was implemented.
This was clearly wasteful, so why it happened? Turned out, any coding task has to be scheduled in the next sprint and the earliest when it can be done is the sprint after. But meetings? They can happen for whatever long with no limits on the number of participants.
