Interview with Fred George on Programmer Anarchy at GOTO Chicago 2014

Hi, it’s Mike with UGtastic. I’m here at GOTO Conf 2014. I ‘m standing here with Fred George, the programmer anarchist, who’s going to be talking about programmer anarchy. Thank you very much for taking the time to speak with me. What is programmer anarchy? I mean, I don’t see a big A on your shirt. I do have one of those t-shirts. Well, actually, programmer anarchy is kind of a sort of a natural refinement of the agile processes. I think the more you push agile processes, the more you learn over time about how fast things can go and get going faster and some other things. And so basically, it was a label I applied that’s very controversial. But it does have the traditional sense of anarchy, which is a team that’s basically self-organizing. It doesn’t mean chaos. It doesn’t mean chaos, which is number two definition. But number one definition is a group that the organization is actually determined from within the group rather than being imposed from the outside of the group. There’s a little book that’s kind of interesting called The Invisible Hook, which was about the social organization of pirates. And you think about it, pirates didn’t have a rule book that says you’re going to be captain, you’re going to be captain for three years, then you’re going to rotate to first mate, become captain. There’s no rule book. There’s no rule book there. And you wound up seeing these pirates basically morph their organization as they needed to. You get the ship from A to B. This guy who’s very good about organizing people who’s fair will be in charge. But when he gets to be attacking that merchant ship, it’s some other crazy dude waving his saber, jumping across, doing silly things. And so to some degree, you want the team to be the same way . So here’s a team. Here’s a problem. You guys organize yourself. And it may be over time, projects change. Their focus changes. The needs of a project change. You may need different people in there. But you want that organization to know that. Because they’re the people who know it the best and when those critical points are. People from the outside are looking in, maybe doing reviews , trying to do stuff like that. They don’t really know the magic moment when changes are necessary. Even when you can afford to roll somebody off. So basically we try to push that back into the team. So basically this is kind of the self-organizing team concept under a very controversial label. Right. Or is it more just trying to use that term, anarchy, to encourage? Or is it more just trying to use that term, anarchy, to encourage? I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. Okay, so it’s just kind of putting out a seed for people to pay attention and hear the word, but also to be able to hear the word. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. I think it’s more just trying to use that term, anarchy, to encourage. But to get them thinking about, no, we don’t necessarily need to have always top-down, out-in organizations. I’ve got to say, I didn’t really come up with the term. I’ll take credit for the term, or take the blame for the term. But the organization itself was something I observed in one of the companies I worked with in London. And basically it was a small group, but they basically started doing these things. First of all, they didn’t have any project managers. Oh, really? Nope. It was the idea that we’re programmers, we know how to get this stuff out the door. Who’s project manager necessary? I don’t need any BAs. I want to talk to the customer directly. I don’t need any QA, because QA is a very complex process and complex systems, and it sounds like programmer work to me, and architect work. So we came up with this kind of very flat structure that says we’re developers. In fact, we actually got rid of all the even managers of the developers. It wasn’t a concept of a manager of a developer. So basically it’s just developers that gets the code out the door. And we kind of pushed up the interaction level with the customer. We sort of started out, in most Agile things, it’s about stories. It’s like, customer will sell a story, we’ll do it. We’ll tell them, they’ll tell it. Next story, let’s do it. Tell me another story, let’s do it. We wanted to re-raise that up to say, tell me what you want to accomplish and then get out of our way. Because we know how to best execute this. We’re smart, we can pick up domains. They say, oh no, you don’t understand, my domain’s really complicated. You’re saying, gee, you think your domain’s more complicated than Clojure? Or more complicated than the tools I work with? I’ll switch with you one of these days, we’ll sort of see. But you don’t think I can understand complex stuff? You don’t understand my world. Right, right. Programming is complexity. And we embrace it. Right. It’s coming at us like a fire hose, we absorb it, and we keep doing this. So, accounting, I’m sorry, accounting’s pretty well the same as the Phoenicians had, you know. And you look at these various fields and there’s nothing really new there compared to the rapid change that we have in our domain. Right. Yeah, it’s a codifiable system in that you can write it in code, but almost codifiable, I mean, code itself is almost not codifiable. It’s kind of crazy. And one of the things we take advantage of is how fast we can go now. So, you know, with the advent of the cloud. I can now get virtual machines quickly, and it’s not a matter of having to plan what’s going to happen for the next year and go get the capital budget approved. I don’t do those things anymore, I get one in five minutes. And if it’s making money, I get another one in five minutes . You know, it’s not a matter of having to pre-plan all this stuff. And so as the cycles got faster and faster, this concept of specializations becomes more difficult to implement. You know, the handoffs between various people can be absolutely crazy. Yeah, and with the focusing on the micro focus that kind of makes me think about the microservice. But you’re also known for talking about is that are these related, is the anarchy and the self-governing similar to like the goal of keeping services very small and focused? It turns out they dovetail very nicely. You know, I originally thought there would be orthogonal issues, that there’s this process, and there’s architecture , and they’re orthogonal. It turns out they’re actually highly interrelated. We wanted to go faster. Our business allowed us to go fast. We were doing Internet advertising through Google at the time. And you get feedback cycles that move 20 minutes. We had a 10-minute time frame from something I’d do in Google to 20 minutes to start getting feedback about it pretty fast. And it was a cycle of times that kept driving us to, okay, eliminate the specialist. Let’s do a separate QA process. Let’s use some techniques like A/B testing and some other things like that to sort of keep driving new code out there . We got to the point where we were delivering something new into production about every three and a half minutes. You know, prodigious, prodigious. Yeah, three minutes. You talked about 10 hours in the previous interview from idea to inception. But now you’re talking three minutes from idea to inception . Well, it was the average. Every program is basically shipping twice a day in the cost of your entire organization. And it would ship something small. It’s a small enhancement. It either works or it doesn’t work. If it doesn’t work, stop doing it. If it does work, you know, feed on it. Let’s do something else. And we basically created a feedback system that let us work in these domains that have fast feedback. We were able to exploit these domains. Frankly, we avoided any domain that would say build a product and you’ve got to figure out it’s going to take six months to figure out whether it’s successful or not. We stayed away from those domains. We’re in e-commerce. We’re in Internet advertising. That sort of thing. When I hear about small, self-sufficient teams, ironically, I think more about the military and the squad structure where you have the smallest unit of self-organized internal structure where everybody communicates with everybody else and they can all work off of each other. But they still have to be able to operate inside of a large unit. It’s a larger system. Even though these programmers are working independently and able to define their own way to deliver, but they still have to exist inside of an ecosystem, a larger organization sometimes. Well, how do you… Even going back to, again, squad systems, particularly in some of the Western militaries, are a very good example of this. They’re given objectives. Here’s the objective we want to accomplish. We think it’s going to… We think it’s going to succeed. We think it’s a good chance of succeeding. But we know that when you get in there and actually try to do it, trying to micromanage you remotely is not going to work. You’re going to be in that environment. They’ve cross-trained around skills. I mean, they’re basically very poly-skilled workers in their own right. And that works very well. But setting the objectives at a high level, very important. Telling them how to execute the objectives, not so important. You want to train them. You want to make sure they have the right skills and the skills across the team cover the whole spectrum of things they might run into. Right. But they can also run into something completely surprising. They’ll either innovate or they’ll withdraw. I mean, they do the right things. And you want the programming teams to be very much the same way. Yeah. And looking at not just programmers, but stepping outside of our day-to-day programming world, because I’m focused on the community as well, and I look at user groups, do you see any correlation between the desire to self-def ine what you’re working on being reflected in the community at all, or is that totally… There’s some analogies there. I mean, to some degree, you look at some of the best open- source projects, and you look at, okay, who’s the manager, and who’s the business guy, and who’s the QA team? They’ve got those roles. Right. They’re basically definitely self-organizing. You know, if you guys sort of own the commitment rights, and everyone else is sort of contributing, and they get invited to the party if they’re a really good contributor, and they can be inside the group. But basically, it’s the same sort of structure. See, the same thing is about startups. You know, you get a new startup, and everybody knows what they’re working on. As a programmer, I know exactly what business we’re in, and I know what the marketing stands. But somehow, when we get these things a little larger, we feel a need to put a CTO in place, who’s going to shield me from this, and the business team is going to shield me from this. And all of a sudden, in this organization, I’m not sure what I’m working on and why I’m working on it. Yeah, and when you say shield, it’s like all about encaps ulation. And maybe even that sounds like even protection. You know, they want to protect themselves, and it becomes a little bit of a… Like, you want to put up these barriers to protect your own interests. Well, to some degree, it’s also VC. VC is sometimes pushing you to put a formal structure in place because they’re thinking about, “Okay, you’ve got to become SAP one of these days. We need the structure, and you’ve got to have a guy named a CTO. You’ve got to have a name, CFO. You’ve got to have these titles.” And people start thinking about the title as actually part of their job instead of, “Hey, we’re still trying to solve problems. We want to make sure everybody understands what problems we ‘re trying to solve.” Right. So, with the company in London, we kind of went out of our way to make sure we never put that structure in place. Right. And if we ever try to do that, one of my roles was to make sure it says, “No, no, we don’t want this sort of organizational structure. We want to keep ourselves fairly loose and undifferentiated at some level, keep our resources flat.” And we made it very successful in business because of that. And just one thing, as we were walking into this interview, I asked about social anarchy. Are you looking at – I doubt you just used the term “an archy” just strictly to be controversial and get people’s attention. Actually, it is pretty much. It is pretty much your set? It is strictly a marketing term. If you peel back the covers, we still believe in basic principles of Agile. We believe in feedback. We believe in communication. We believe in simplicity. We believe in courage. We believe in respect. It’s just that when you start putting practices around this , particularly in light of microservices, all of a sudden a microservice is 20, 30 lines of code. Do we need a unit test? Probably not. It’s only 20, 30 lines of code. If you can’t do that, find yourself a new career. And we don’t care what language you write in. Because it’s running independently of every other piece of code. And so you could write one in Ruby. I could write one in Clojure. And you could turn around and say, rewrite mine into Visual Basic. I don’t care. Because it’s RESTful interfaces and JSON packets. In fact, run some in Node. You don’t care. And so all you’re really asking people is understand what it is. And if you don’t like it, replace it. It’s not a matter of having to refactor it. In fact, why would you use design patterns? It’s 30 lines of code. Why would you worry about any of these sorts of things? Because it’s 30 lines of code. And all of a sudden processes fall away. It’s not 30 lines of code, though. So it’s kind of like cells of your body. You think about it. You’re still you. But none of those cells that you were born with are there anymore. They’re dead. They’re gone. They’re gone. But you’re still you. But you’re a complex organism. And so I think our systems are very complex. We talk about systems that have millions of lines of code in them. Whether it’s broken into 30 line services or one giant 3 to 10 million line of code tarball. It’s complicated. You still don’t know how it’s working. So you don’t necessarily lose anything. With microservices in a complex environment, you don’t necessarily gain anything either. Except if you happen to be outsourcing this piece of code and you just turned out to be a horrible programmer. You write this really ugly microservice. The impact is only the service. I can rewrite 30 lines of code. I can rewrite it. The damage you can do to my applications is very constrained because of microservices. So by keeping things super small, you’re able to say, “Okay , if there’s something that goes wrong, you can narrow it down onto one.” Exactly. Instead of having to be like, “How do I replace this mon olithic?” I think that has all these inner connections. And some of the problems with object-oriented systems that we’ve discovered over the years is, “Yeah, so you build a really lovely object-oriented system that has all these same traits, but here comes a programmer who doesn’t know anything and he starts ripping the data out of it. Starts publishing getters and setters all in his method. Starts pulling the data out. Now everybody knows this data. Everybody’s running the algorithms every place. Now you can’t change anything.” Right. A microservice, it’s a little hard to go in there and grab an internal piece of data. Right. I mean, unless you’re going to open this up and put a new API in it. Right. So actually, it’s sort of an encapsulation carry through to a real extreme that’s very powerful. Okay. Well, thank you very much for taking the time to speak in here. We appreciate it. Thank you. User groups with lots to say, interviews and more. No way. Sharing great ideas in the tech community. Fascinating conversations, a plethora of information. Find out for yourself today at ugtastic.com. I’ll see you next time. Bye. Bye.