Ep. #20, Is Bimodal IT BullshIT?

Paul Biggar: As soon as you use the word IT, I'm switching off almost immediately. My sense on this is they've packaged up waterfall.

Edith Harbaugh: If your alternative is complete chaos in software development, waterfall looks like a good idea.

Paul: If you take the worst possible practices in the world, then yes, a practice that is merely bad practice is going to be better than that. What I'm picturing here is like a giant straw man flowing off Niagara Falls.

Edith: I think waterfall is better than chaos.

Paul: As a firm believer in continuous delivery, I think waterfall is chaos. Did you ship it? If you shipped it, then it probably wasn't waterfall. The whole problem with software and the reason it's different to like building a bridge is you rarely know where the finish line is.

Hi, I'm Paul Biggar, founder of CircleCI.

Edith: I'm Edith Harbaugh, CEO and co-founder at LaunchDarkly.

Paul: And you're listening to To Be Continuous, a podcast about continuous delivery and software development.

Edith: You can get in touch with us anytime at our Twitter handle, @continuouscast.

Paul: The show is brought to you by Heavybit. To learn more, visit heavybit.com. And while you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.

Gartner's Bimodal IT

So this episode, I think, is gonna be a very hateful episode, very ranty.

Edith: This is the Hateful Eight, the Quentin Tarantino of episodes.

Paul: Definitely going to be, and I think this happens when you're discussing something which comes from Gartner.

Edith: Gartner.

Paul: Gartner. But Gartner. I like Gartner. There's just a lot of legacy in how Gartner talks about producing software that a lot of it I don't agree with.

Edith: Yeah, so recently they came out with this report and they're pushing a theory called, well, they came out with it in 2015, and it's called bimodal IT.

Paul: Well, as soon as you use the word IT, I'm switching off almost immediately.

Edith: And why do you switch off?

Paul: The word, it's sort of like community signaling. It's like if you talk about tech or software or engineering or something like that, you've got an understanding of, like, it implies to me that you know how to build software. And if you talk about IT, then I hear someone holding the purse strings as a top-down CIO, ancient corporate thing. Which of course is the world that Gartner lives in, so no wonder they're using the word IT all over the place. But I don't think I know any engineers who would describe what they do as IT.

Edith: Well, I do think you have kind of a self-selecting sample because you live in San Francisco.

Paul: Deliberately so.

Edith: Alright. So basically Gartner's approach, which I disagree with, but I'll describe it, they basically tried to break up software development into two modes. And they called the one mode of IT more the systems of record, the big banks, the slow. I'll just read off how they described it.

It's all about reliability, it's all about plan-driven, it's about things that are far from a customer. So basically like back-end systems.

Paul: Okay. And this is mode one?

Edith: Yeah, this is mode one. They say think marathon runner. Like kind of slow, steady, reliable. And the path two they describe as the agile sprinter. Which is more about continuous for new projects, for things that are very customer facing.

Paul: Yeah. I'm looking at the graph here, or the chart, and it really seems like mode one is waterfall and mode two is agile, or at best, at a very close approximation.

Edith: So I think it's Gartner basically trying to break up the vendor landscape because that's what they do. They try to...

Paul: You can take a vendor and put it into mode one or mode two.

Edith: Yeah, and they're saying, based on your project, here's...

Paul: I'm gonna say without any shame or fear of being wrong, but that if your CIO buys from a mode one vendor, quit now.

Edith: Quit now.

Paul: Quit now. Like, that's it. I'm walking out the door.

Edith: Well, so Jez Humble wrote a brilliant comeback, which I'll acknowledge right away because I'm a huge admirer of Jez Humble, where he's basically like, this is bullshit.

Paul: Okay. So I read his comeback and I agree that it is bullshit, but I think it's bullshit for different reasons than he thinks it's bullshit.

Edith: Let me summarize his, just for those following at home. He basically said that this is bullshit because these two systems interact together. Like the argument that we have our back-end slow systems and our front-end fast systems, so they could go on different paces, is ridiculous because they need to talk to each other. Like if you're a bank and you've really had a new website, it needs to talk to a back-end system and you can't really iterate.

Paul: I mean, is this not microservices that we're talking about? You have two different services that operate at different paces. Is that not possible?

Edith: And he also said that the best companies like Toyota iterate on both axes at the same time.

Paul: Right, right. I noticed you mentioned Google and Amazon a whole lot.

Edith: Yeah, like, you can't say, okay, these systems are really slow and reliable and these are fast and agile, and that somehow we'll come up with a winning combination from this.

Paul: Right. So slow cannot be reliable in my...

Edith: Yeah.

Paul: I'll come to that. What else did Jez say?

Edith: Well, that's a summary and I encourage everybody to go read his whole article.

Paul: It was quite good. My twelve second skim of it. I was impressed. So my sense on this is that they've packaged up waterfall into a best practice.

Edith: I think waterfall is very comforting to some people. Because they think of waterfall as a way in which they were more in control.

Paul: Right, right. So there's a lot of upfront planning and that sort of thing. I think people are more comfortable. I mean, there's something very seductive about the idea of, we will spec it and it will be right and then we will deliver that. I just don't think that it's good, realistic, I mean, any sort of way to deliver software.

Edith: Yeah, I agree. But I think this is what Gartner is trying to say, is that like, hey, agile seems very frightening. So when you said, oh, this is repackaged waterfall, you say that like it's a bad thing.

Paul: No, I do, because they're saying that it's valid to like, I mean, essentially what they're doing is they're allowing people who are stuck in the waterfall world to be like, oh, waterfall is perfectly valid. We'll have like two projects that do agile and keep the majority of the company on...

Edith: Yeah.

Paul: So perhaps as a migration path, where eventually the people who think that die or retire, then yeah, maybe. But if they're actually presenting this, or if they actually believe the thing that they're saying, where this is a valid way of producing software, I think they're batshit.

Marathons and Finish Lines

Edith: Yeah, and I agree. I mean, so the example they gave is waterfall is more like a marathon runner and agile as a sprinter. I think as a marathon runner or as an ultra marathon runner, you have to be extremely agile when you're running. Like you're constantly changing your plan.

Paul: Right.

Edith: You're constantly like, am I...

Paul: And that's when you know where the finish line is.

I mean, the whole point with software and the whole problem with software and the reason it's different to like building a bridge or something like that is you rarely know where the finish line is.

Edith: Yeah, that's such a good metaphor.

Paul: But you don't even know what it means to have...

Edith: To be done. So when you run a race, you at least know here's the endpoint. How much food do I need?

Paul: Mostly, you know the path as well, right? You've possibly run this race before.

Edith: Yeah, and I think with software it's more like you don't know where the finish point is. There is no finish point in fact because if you're successful, you'll be continuing to evolve. Like Amazon started off as a bookseller. Now they sell cloud services. If they'd said, hey, we're gonna take this bimodal approach where like we have our steady book system and we're just gonna iterate on the front end, they would never come up with AWS, which is where they actually make all their money.

Paul: There's an interesting thing in this chart of like, the culture is IT-centric removed from the customer versus in mode two, it's business-centric where it's close to the customer.

Edith: Yeah, which I think is ridiculous.

Paul: I mean, what crack are they smoking here? I mean, it's like they're saying that it's okay to have a mode in which you're removed from the customer.

Edith: Well, it's basically kind of a sop to the old world where it's like, hey, we release every three years and nothing changes. I heard a really interesting story from, do you know James Smith of Bugsnag?

Paul: Yes, yeah, yeah.

Edith: He used to work at Bloomberg and he said they had some pieces of Fortran that were mission critical but yet nobody understood.

Paul: Of course not.

Edith: And so they literally could not...

Paul: As soon as you say it's mission critical, then no one's allowed to touch it, so no one will touch it, and so no one will understand it. Your bus factor goes down to zero, no one can do it.

Edith: Yeah, so now they're kinda in this bad state because it's mission critical, but they cannot improve it. 'Cause like, it's like, well, nobody understands it. So they took this mode one approach of like, hey, this part is done. And now they're kind of in this hole because it's written in Fortran. Versus if you go more than mode two, of let's always be improving, they would have iterated to a better language or better.

Paul: You do end up in this situation sometimes. I think that you do need a tactic to get out of it. I think it's not a particularly hard thing to do. You put an API in front of it, you try to build something else that matches the API, and then you feature flag your way into it.

But I certainly, I think anything where you're looking at long cycle times, where you're looking at fear of touching a component, anything where you're not constantly delivering the customer value and getting feedback from that value is just a disaster.

The Risk of Long Cycle Times

Edith: So what do you think are the pitfalls of that model?

Paul: It's one of those things where when you're doing a continuous delivery podcast and you have a continuous delivery company and you like live in this continuous delivery mindset that it's been quite a few years since I've had to...

Edith: And you wear a continuous delivery t-shirt.

Paul: Right. I mean, the major pitfall is risk, right? This is why we love continuous delivery. I'm sure we've talked about risk in every episode so far. If you have a long cycle time and you're going in the wrong direction, to go back to the race analogy, it'll be a long, long time before you discover that you're going in the wrong direction and you may be unable to find your way back.

Edith: Yeah, or you could have just driven yourself off a cliff to go on the race.

Paul: I mean, essentially what you're saying in this is we're gonna close our eyes and drive according to the plan. And if the plan is wrong, or we don't actually know how to follow the plan...

Edith: Or there's not a car that we're in.

Paul: Exactly. Yeah, yeah, yeah. There's an interesting thing here that they talk about, approval-based. I mean, this is kinda how I think about this world. It's like, do you have the phrase jobsworth?

No, so it's a phrase you have in Ireland, you probably have in England as well, but the idea is that you only do exactly what's in your job description.

Edith: Oh yeah. Like work to the hour.

Paul: Yeah, yeah. Work to rule, all this sort of thing. And it's kinda like no one got fired for buying IBM, right? You do something within your job to stay employed, but you actually don't give a shit about the project being delivered. You don't care about the company.

Edith: Garbage in, garbage out.

Paul: Yeah, exactly.

Edith: I built what you told me to build.

Paul: Exactly. And so when it says like plan-driven, approvals-based, it's like, all right, no one's getting fired for implementing this plan that has been approved, but everyone should be fired for agreeing to go along with this.

Edith: It goes back to something we talked about a long time ago. How much leeway does an individual have to say, like, this entire thing is kind of broken? Like if you're at this big organization where it's like, okay, you do what the spec says to do. You do what the spec says. And I think people are scared of mode two.

Paul: Yeah, I mean, anything new is scary. I mean, the way that people deal with fear a lot of the time is they sort of clamp down on it, and they put approvals in front of it and they're like, I wanna see everything that comes out.

And so when you move to agile, and I'm gonna use the agile with a small A, process, like constantly changing what it is you're doing, you're constantly changing the direction you're in, you're pathfinding very effectively, but you're acknowledging that you don't actually know where you're going. I mean, yeah, it's scary times.

I mean, it's like scary times until you've done it a few times. Once you've done a couple of cycles like this, nothing looks scary at all. It's scary to think that you could plan your future.

Plans and Planning

Edith: Yeah, well, it goes back to the whole thing about like, should a startup do a five-year plan? And I don't think they should do longer than a three month plan, to be honest. Like, you should have a five year vision.

Paul: Yes, yeah. A vision, definitely. But like, you could argue, and I think that this is actually quite a thing to do, is that you have, let's say, a three-year plan or two-year plan, let's say, and you redo it every month.

Edith: That seems like a lot of overhead.

Paul: Maybe every month is a bit often, but like, you redo it as soon as you get feedback. So when I'm looking at what I want to do for my personal productivity, I have a month plan, a week plan, and a daily plan.

Edith: And on Tuesdays we do the podcast, right?

Paul: Yes, exactly. So I put in what I'm going to do this month, or what I plan to have accomplished. And frequently halfway through the month, I'll realize that the things that I wrote at the start of the month will have been wrong. And so I redo the monthly plan.

Edith: Yeah, but I do think there's a big benefit in writing it down.

Paul: Yeah, yeah. Like, plans are worthless. Planning is essential.

Edith: Yeah, like so for our startup, like every month we talk about our big picture goals. And then for every week we break it down, like here's what we're gonna do this week. And we're not blind.

Paul: But all this is a very mode two thing in Gartner's thing. I don't think anyone would say, like, first we will build the software, then we will QA the software, then we'll deliver the software, then we will hire the salespeople, then we will sell the software. I guess the engineers are twiddling their thumbs at this point.

Edith: Well, I do think there is something to, you know, you staff to demand. You build an MVP and see if you can attract people to it. You do some marketing, see if your marketing is successful.

Paul: You iterate, you use the feedback that you have to get somewhere. All fundamentally agile stuff. I would be shocked if anyone on the left side of this left side of the chart in the mode one thing has any sense of using feedback in there to guide, I mean, you can't if by definition your cycle time is long.

Healthcare.gov and Challenger

Edith: Well, I think a classic example of this is healthcare.gov.

Paul: Right. The first version, not the second version?

Edith: The first version, which was very much like, hey, let's build the system. Everything has to, you know, and then we'll try to manage it all as a very large scale instead of, hey, let's try to break this down into smallest chunks as possible to deliver value.

Paul: I think that the jobsworth thing that I was talking about becomes inevitably part of one of these large government IT contracts where you have someone, thousands of people executing the plan and getting paid, and no one can see the wood for the trees, possibly willfully.

Edith: Sometimes willfully, and sometimes even if they say it, they're branded as a troublemaker.

Paul: Whistleblower.

Edith: Yeah, shut up, code. You know, who cares if it, like, the classic is the poor engineers of the NASA Challenger. Do you know Challenger?

Paul: Yeah, there was a shuttle accident, people died.

Edith: Yeah, so Feynman was one of my heroes and he wrote a book 'cause he was part of the investigation. And basically the engineers at the contractor were like, we cannot do this launch. You know, it is colder than we've ever done a launch.

Paul: Oh, interesting. Okay. Like, so something shattered because of the cold, was that right?

Edith: So they had an O-ring, which was basically an expansion joint. Like, it's basically a piece of rubber that expands and contracts when the rocket is taking off. So what happened, because it was so cold, is rubber is brittle. And so it couldn't contract properly.

And so the engineers the night before, like, it was in Florida, but it's like, it's colder than we've ever been launched. We cannot do this. And they were, you know, they were just basically saying no. And then their superiors are like, wow. This is a long tangent.

Bezos on Type 1 and Type 2 Decisions

Paul: So I saw a very good split between mode one and mode two recently. And this was in Jeff Bezos', I think, annual shareholder talk about how we do things at Amazon. And so it's not the same mode one, mode two as Gartner, but it's a very, very similar thing. And he split things into mode two, where we expect to fail a lot, and mode one, where failure is really not an option.

So something where like we give all the Kindles away to make it up on books, that's a mode one. You sit down, you do the plans, you do the financial models, you really work this out.

And mode two is like, we launch a Fire. Like, we don't get anywhere in the marketplace. Fine. We do, amazing. And a lot of the successful things like Amazon Web Services, like Alexa, were all like mode two projects that they threw ten things against the wall and one of them stuck, and then they quietly, or not so quietly because you're at Amazon scale, that people complain when these things go away, but you know, they killed nine of them.

Edith: Yeah, but I think Jez Humble's point, and I think what you made before, is that even in mode one, you have to realize that failure is not an option, but failure can happen. And how do we build a process against that?

Paul: I guess I'm misquoting and poorly paraphrasing Bezos to say failure is not an option. It's much more, there are some things that you need to do methodically and be very careful about. And these are very, very few and far between.

And the vast majority of organizations proceed as if everything is a type 1 decision, when in fact the vast, vast majority are type 2.

Edith: Well, I think that's because a lot of organizations don't have a culture where failure is cool.

Paul: Right, right, exactly. But I mean, there's inherently a tie between this we can fail, and we're shipping with short cycle times, because really you can't fail when you have long cycle times.

Edith: Yeah. No, if every moonshot takes three years, you can't fool around.

Paul: And it becomes inevitable that when you start to have these really short cycle times, you see that the cost of failure is really low and the benefit of trying things that might not be successful is really high.

I guess that's where I'm drawing the analogy between Gartner's type one and type two, or mode one and mode two, and Bezos' type one and type two. They're fundamentally kind of concerned with the same thing, but one of them is just like this throwback awful thing, and I think Bezos really nails how to think about those different projects.

Edith: Well, I think, so I'll sum up, I love your example of running because I like running. I think mode one is more like everybody is Steve Jobs, they know the exact right direction to go in. Versus, hey, none of us are Steve Jobs, and let's kinda like wiggle our way in the right path and figure out if we're going the right path. And by the way, even Steve Jobs was not Steve Jobs. Like, he had many very expensive mistakes.

Confidence in the Pitch

Paul: Yeah. I think one of the most damaging things as well in the industry is people who think they're Steve Jobs. Damaging to themselves.

Edith: Do people still think that?

Paul: I mean, it was a thing like three or four years ago where everyone you talked to who is in, at least in, sort of the startup-y part of the world, would think they were Steve Jobs.

Edith: Yeah, I've never thought I was Steve Jobs. I've always, when I was fundraising, I think it was dinged a little bit. 'Cause sometimes I would say stuff like, we have some marketing ideas, but we don't know which one is right.

Paul: Oh, right, right. They expect some sort of certainty. People find confidence to be very attractive, is a good word, but in the, you know, the sort of thing you want your CEO to have is like confidence, and you feel a lot of confidence investing in someone who's confident, even if it's ludicrous.

Edith: That's what I figured out. And then I could put my, you know, say it much stronger. Like, we think content marketing is going to work out. And it was the exact same thesis inside of like this content market.

Paul: I had exactly the same thing when I was raising Series A and so I was going down to Sand Hill Road a lot. And I'm very much of the, you know, I don't know what's gonna work. I don't know the right way. You know, I'm sure we'll figure it out. We'll try things and we'll get there and we'll work through our mistakes to get there.

Edith: Investors do not want to hear that.

Paul: Right.

Edith: Investors do not want to hear that. They want to hear, like, hey, we're gonna do content marketing. Here's our plan.

Paul: So what I did, and I remember this vividly, like I remember sitting in the parking lot in Kleiner Perkins at eight in the morning. I'm the only car in the car park and I'm blasting Lose Yourself by Eminem as loud as I possibly can. I'm just sitting there and I'm fucking shouting. And it's, you know, the way to instill the confidence that they expect you to have.

Edith: Yeah, it's funny 'cause I got the exact same feedback, and I think it's 'cause we're very similar, but it was like, you know, sit up straighter, be more authoritative. And inside you could still be, because in my head I thought I was being very analytical. Like, we have some strategies, we don't know which one is right, but we work through this, there's like, no, say you have strategies. And that you're Eminem and you're gonna...

Paul: This is quite the tangent, but there is a strong correlation between someone who can lead and someone who's like confident in their decisions. The pattern that I, giving VCs the benefit of the doubt here, is that they're looking for someone who can, you know, take a ragtag group of misfits and lead them into battle and come out successful the other side. And many startups, that analogy kind of applies.

Edith: Well, that's very true. I mean, you're basically a squad leader.

Paul: Right, right. So you want to see that confidence from your squad leader.

Edith: Yeah, I mean, so I grew up in DC, so I kinda grew up going to DC and seeing a lot of World War Two movies. And there's this classic plot line of like, you know, the leftover squad. Who's actually like all have these, the A-Team, and you assemble them to something that's stronger than all the parts and you lead them to victory.

Paul: And the leader gets, you know, starts out a little bit tough, no one really likes him, but then he manages to pull a vision together when they get trapped behind enemy lines.

Edith: It's basically also the plot of Star Wars, by the way.

Paul: Who's the leader?

Edith: Well, I would say it's Princess Leia.

Paul: No, I think that's probably right. So Star Wars good, Gartner bad. Is that our conclusion?

Edith: I think Gartner is good and that...

Paul: No, I actually think it is as well. I'm being a little bit facetious here. I wanna walk back on that last thing.

Edith: I think there's still a fair amount of fear around what agile really means in terms of control.

Paul: It's only been around like 12 or 13 years at this point. I expect that people would still fear it.

Edith: I don't know if you're being facetious or not.

Paul: That's facetious.

Edith: So Gartner's message right here is, fine for your young, risky projects, go off and do this fresh new thing, agile.

Paul: So no matter what, I think, don't listen to Gartner on this.

Every project is a type two project. The risk is lower. Long cycle times kill you. Even if you're on the, you know, piece of Fortran that no one can touch, like you can continuously deliver your way out of that far better than you can do a mode one project out of it.

Thanks for listening to this episode of To Be Continuous, brought to you by Heavybit and hosted by me, Paul Biggar of CircleCI, and Edith Harbaugh of LaunchDarkly.

Edith: To learn more about Heavybit, visit heavybit.com. While you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.