Thanks to a combination of illnesses, travel, timezones, and the other horrors of the modern world, we took a week off. If Angular can skip version 3, we can skip episode 3. Welcome to Episode 4 of Software on the Rocks, brought to you by Atalasoft.

In today’s episode, we are joined by TDWTF author Jane Bailey. We talk about the process of writing, the nature of programming, and “programmer anarchy”.

This episode of Software on the Rocks is brought to you by Atalasoft.

MP3

Web Player


We’ll be back in two weeks, when Alex and Remy finally have a duel to the death. Two programmers enter, only one programmer leaves. Follow future episodes here on the site, or subscribe to our podcast.

Transcript

Alex: So, I guess this is episode number three now, if I’m keeping track, right?

Remy: So, that makes three episodes that you’ve started by saying, “So, I guess this is…”

Alex: Oh, look. We’ve got – I don’t know. We’re not doing these right after another. Podcasting is pretty new to me, and I don’t know. I think this is a lot of fun. I’m enjoying it. And from what I can tell from reading the comments, the readers are absolutely enjoying it, too. Remy, I want to read this one to you. It’s from Ross, and then in parentheses, “unregistered.” So, let me read you his comment, because it, I really think, speaks to the heart of what we’re doing here. [Clears throat] Okay. “Not that anybody at The Daily WTF will care, but I, too, have no f---ing interest in The Daily WTF podcast, or any other podcast whatsoever. I won’t listen. I won’t read the transcripts. I’m hoping that you continue putting ‘Software on the Rocks’ in the title so I can get my RSS feed to ignore them.” Eh? That’s exciting, yeah?

Jane: Sounds about right. Yeah, that’s what we hope to hear. [ Chuckles ]

Alex: Here’s another commenter that says, “This is just terrible and an absolute waste of time.” They won’t come back, and it’s sad that they won’t hear me thanking them for sharing all of this great feedback to them, but, nonetheless, I’m happy that they listened to at least our first two episodes.

Remy: Hello, everyone. Let’s actually do our introductions. I’m Remy with Alex Papadimoulis, and we also have, today, Jane, who you may know as Bailey from The Daily WTF. She’s one of the writers, contributes a lot of great articles, so I wanted to introduce her and give her a chance to say hello.

Jane: Remy, I am always having fun, but now more so than ever.

Remy: Bailey actually joined the site – It’s a couple of years ago now – shortly after I took on as being chief editor. But as part of me single-handedly ruining the site, I brought in a bunch of people who hadn’t written for the site before and said, “Start writing for the site,” and Jane was one of those folks.

Alex: I think it’s great. The commenters, again – They also seem to just hate it. But they’ve f---ing hated everything ever since day two of the website; so still, we’re on that continued decline from our height. I didn’t really think that Daily WTF would ever evolve into this sort of – I guess you could call it – what? – I.T. fiction? Or I guess you could call it I.T. based on true stories. But it’s really interesting to read, and it’s a fun blend between sort of our day jobs and fiction that captivates and tells stories.

Remy: I don’t know about you, Jane. I have a very specific process I use for turning a submission into a story. Our readers often accuse us of fictionalizing too much or anonymizing too hard. I don’t know about you personally. I actually don’t do very much of that at all. Personally, if I’m fictionalizing, it’s because the submission itself didn’t contain a lot of details, and the details I add are almost always from, like, real-world experiences I’ve had.

Jane: Yeah, I absolutely agree. Sometimes they’re details of coworkers I’ve spoken with, telling me their horror stories, or other things that I’ve seen around The Daily WTF forums, but more often than not, they’re just things that I have seen, you know?

Alex: You know, certainly a lot of folks have written in or have commented and said, “Oh, this is clearly a fabricated story,” or “clearly, you’ve made up a lot of the details.” But, you know, what I think is more accurate, or certainly worth considering, at least, is the folks telling these stories are the ones who have forgotten almost all of the details. Every time you retell that story to your friends, to your coworkers, to whomever, the story gets more and more muddled. So, the reality of what actually happened is really vague to begin with, and if we were to break down those – the bits of the story that they actually share, it would be really boring and certainly no one would be reading it. One of the best bits of feedback that I’ve ever received was from a guy that I met who had sent in a story. He said that “You changed every detail in the story for the most part; however, after I read it, it felt more like that’s exactly what happened than in my own mind.” And that, to me, was a good way to sort of recreate an event in a fictional sense.

Remy: I kind of always think of it more like, back in the ‘50s and ‘60s, you had the “true crime” writers, right? And they would take real-world news stories – you know, murders and gang killings – and they would turn them into these novels that had a lot of fictionalized details. They certainly played up the more salacious elements of the whole thing. But their goal there was to take something that was based in reality, decorate into something that was also entertaining.

Jane: I think some of my favorite submissions are ones where the submitter has clearly not understood what was the most interesting part of the story or possibly is completely in the wrong about what was happening and should have happened to where I can really punch up someone else’s viewpoint and tell a much better story than they submitted just by virtue of, you know, having – being an objective observer and saying, “Well, what you submitted was okay, but this part – this part’s great.”

Alex: Do you guys happen to remember the ITAPPMONROBOT story about the –

Jane: Oh, yeah. Of course I do.

Remy: Oh, yeah.

Alex: It’s one of my absolute favorites, but if you go back to the original submission, and I don’t know if we’ve ever linked it. I know we shared it with the writers, obviously, as well, but, you know, the original submission, if memory serves correct, had to do with an anti-Windows – It was a “Windows is terrible, Linux is great” story. And to the submitter, that was the notable part is that Windows was so bad that he couldn’t reset the server remotely, so he programmed a Linux box to eject a CD drive. Mm, that’s kind of lame. Just – Who cares? Another “Oh, Windows is terrible” story. But we turned it into a much more memorable story. Same exact set of facts packaged and presented completely differently, and it went from being a rant that would be in the comments section somewhere to a pretty memorable story that is one of my favorites and, I think, a lot of readers’ favorites, as well.

Remy: On Jane’s point, there have been a few times where I’ve picked up a submission where the real WTF in this submission was the submitter.

Jane: Yeah.

Remy: You can read their story, and they’re trying to make this argument about how horrible everyone around them is, but you can see clearly they were the ones who were actually in the wrong. One of my personal rules is that, even if I read the submission and the submitter is the real WTF, I don’t write the story from that perspective. The submitter is always going to be the hero of the story, but maybe we move the actual problem or we express the problem in a slightly different way. There’s actually one that – It hasn’t run yet, but it’s going to run before this episode airs, and it falls kind of into that category. Ellis wrote a story called “The Automation Vigilante,” which – It’s actually about the person that, as developers, we tend to have a big problem with. They’re the non-developer who writes a bunch of macros to automate their job.

Alex: I love that title: “The Programmer Vigilante.” Just the image that that’s conjuring up and – Basically, it describes so many people that I’ve met in my career, as well. On the idea – This concept – So, programmer vigilante – It reminds me that one topic that was sort of on our shortlist to bring up today was something that – It wasn’t programmer vigilante. It was what? It was programmer anarchy. Programming anarchy.

Jane: So, I heard about programmer anarchy when I was looking up, you know, different types of agile and some out-there agile concepts. And basically what it is, as an elevator pitch, is a bunch of developers who fired all the managers, fired all the business analysts, fired all the Q.A. people, sat down with the stakeholders, and said, “We’re in charge now.”

Alex: Oh! That sounds about as successful as real-world anarchy.

Remy: This sounds like the textbook definition of the Dunning-Kruger effect.

Jane: Pretty much.

Alex: So, it’s an interesting concept, and I guess if no actual work needs to be done – Again, let’s say like real-world anarchy – I could see it working. But what is the context that this came from? Is this a methodology that’s espoused by, oh, I don’t know, somebody just who’s been completely embroiled in this Dunning-Kruger effect and thinks this is a good way to run a business?

Jane: Well, and that’s the fascinating part is that it worked really well for them. But the thing is, they started with a bunch of senior developers who really knew the business, inside and out, had been right there from the beginning, with the stakeholders. They worked in an industry that was very fast-paced, to where the biggest risk was not moving. So as long as you did something, even if it failed, you would come away with better payouts than doing nothing.

Alex: So, I guess it’s this idea that it turns out that, yes, they said they fired all the business people, they fired all the other folks, but they were those people. They had knowledge – very specific knowledge of whatever specific industry they were in, which completely invalidates the entire thing. That’s like saying, “Well, anarchy will work as long as it’s these 12 people on this island who will run it like a utopia.”

Jane: Yeah. I mean, that’s basically it. If you have a bunch of high-performing senior developers who know the business like the back of their hand, you could do anything and you would come away with a success.

Alex: Now, what I see we’re doing here, Jane, is that we are building up this wonderful effigy made of straw and then setting it ablaze. So, Remy, I’m hoping that you can come in and defend programmer anarchy.

Remy: I can, actually, Alex. And feel free to stop me, Jane, if I’m kind of going off the path, but I’m almost agreeing, actually, with Jane, even as I say I’m gonna defend programmer anarchy, because here’s a few things to keep in mind. First off, if you are engaged in any creative effort – and programming is a creative effort. I think we can agree on that much. It’s a technical field, but it’s very much a creative effort. If you are engaged in a creative effort, handing the reins to people who are passionate about what’s being created – now, not passionate for the tools, right? You don’t hire a sculptor because they love a chisel. You hire a sculptor because they are passionate about sculpting, right? So, people who are passionate about what they’re making, people who know the business, in this case, right, who are intimate with the business – Jane’s absolute right. You get those people involved, no matter what you do, you’re gonna see at least some degree of success. But here’s the other thing. In a lot of organizations, there is a big pile of management overhead, and I have actually said this many times. If you want to make an organization perform better, fire all the middle managers.

Alex: So, that’s a couple interesting points. Now, first, I don’t think I can let you get away with the
“programming is creative.” You know what’s creative? Music is creative. Sculpting is creative. Um, programming is engineering – solving a very specific problem to achieve a very specific business goal. Obviously, the mechanism of that problem is not well-defined, but that does not mean that it’s a creative endeavor.

Jane: See, I also have to disagree a little bit, Alex. I think you have to separate the act of programming from the more creative endeavor of software engineering. I think there’s a lot of different particular disciplines within, you know, computer science and within the art of making a program, some of which are more creative and some of which are purely mechanical.

Alex: Well, and that’s certainly fair, because software eventually does interact with users, but that’s a whole field of discipline called user experience, which is quite a bit different than, say, “Let’s figure out how to write a process map that takes this loan and runs it through a dozen different underwriting programs.”

Remy: If you are presented with a problem space – Let’s get programming out of here entirely. We’re building a factory. We need to take raw materials through a factory and get widgets on the other side. This is a broad problem space. There is a nearly infinite number of ways that we could accomplish that goal. There are definitely ways that are better than others. There are definitely ways that are almost equivalent but have certain tradeoffs that make them better in certain cases than others. And I would argue that the act of taking a huge problem space and cutting that problem space down to the appropriate solution is an act of creativity.

Alex: Ultimately, what we’re looking at is software that’s designed to implement a business process. A lot of times, software defines that business process, but when we’re saying that developing this code behind a pre-defined – And I’ll give you that there’s a creativity in defining that business process, but in implementing and in software, where’s the creativity outlet?

Jane: Being that, you know, I have my fingers in a lot pies – I’m sort of a modern Renaissance woman – one of the many things I am is a writer, and so, inevitably, my mind goes to try and liken software design to writing a novel – particularly a novel. A short story’s a little easier. But nobody can doubt that coming up with the idea for a novel and, you know, the setting and the plot is purely creative, but at the same time, typing the words on the keyboard is a purely mechanical task, to me, akin to writing lines of software code. There’s only one right way to spell each word, and there’s only a handful of right ways to link them together into sentences.

Remy: Jane, I really love that metaphor, because as you were saying it, it dawned on me – If you are in the process of writing a novel, one of the decisions that is both a mechanical decision and a creative decision is, in the space of an individual sentence, am I going to describe what I’m telling the reader about? I have a character who’s wearing a coat. Do I describe the coat in a literal description or do I provide a more metaphorical description or a simile that conjures a different image than the strict literal description? And that’s something that, if we were to think about this from a programming perspective, that’s a question about what abstraction tools we use to express an idea. So, here’s an example where there is that element of creative thought in programming where I could write a very literal program that uses almost no abstraction, right? I mean, go into your operating system, right? You go into kernel code, and kernel code is extremely literal. It expresses things in a very concrete fashion. For a more high-level language, we are gonna be using these more abstract tools, and that’s where a certain degree of expressiveness comes in, where there are a lot of ways to say the idea you want to say.

Jane: To do it well, at least.

Alex: Well, and I think, though, the same case could be made for every single engineering profession.

Remy: I agree.

Alex: Building a bridge, a skyscraper. But, you know, the difference between engineers, creative professionals, and programmers, who seem to want to live in both worlds when convenient for them, is that engineers have things like schedulers.

Remy: This is where I have to disagree with you on creative work so, so much. Because one of the creative endeavors that I have – and I’m strictly a hobbyist, and I am very bad – but I like directing short films. And if you are going out to direct a film, there are a lot of people and there are a lot of resources that you have to manage through that filmmaking process. That requires schedules. It requires budgets. It requires – You know, you have to have a call sheet that tells all of your cast and crew where to be when and what they’re gonna be doing once they get there. This is where you do need a management organization. And I know I’m kind of contradicting myself, ‘cause I just said, “Fire all the middle managers,” but I want to be specific there. Fire all the middle managers.

Alex: I mean, to an extent, but now you’re talking about – And this, I guess, was the point that I was driving towards, right, is that, you know, on the creative side, of course there’s deadlines, but you know what creative people do. They just work straight up until the deadline. If you want to work the eight-hour days, which, by the way, many, many people prefer to do, because this isn’t fun for them. This is work for them. So, for the people who do want to work those eight-hour days, we really do need to build structures, an organizational system of ways to manage the eight hours that each programmer, each developer, each analyst is able to work each day. And, you know, going to this middle manager notion – Of course they’re very, very valuable. Any good manager – what – eight to ten people? That’s about all that you can really manage as a team. What happens when you have 100 developers?

Remy: I think there’s a lot to mine on this topic. And I’d love to continue that, but I think that’s way too big a topic for this. Let’s pull it back to programmer anarchy as an organizational technique. And I want to hear Jane’s, you know, key thoughts and key takeaways about programmer anarchy.

Jane: Yeah, well, you know, to me, the most interesting thing that I found out about programmer anarchy when I was looking into it – The original white paper that they put together, they talked, you know, proudly about all the things they got rid of. They got rid of all the testing. They got rid of iterations. They got rid of user stories. They went to, like, a microservice architecture where, you know, they felt like they would never have to refactor code again because they can just delete it all and start over because each service was so small. They got rid of paired programming. And two years later, one of the two authors of the paper sat and, you know, went through, to him, how successful it was. And he says, “Well, if you look around the company today, everyone’s doing stand-ups. A lot of people ended up liking the idea of refactoring code because it was pleasant to them to see their code get progressively better over time. And they’ve started doing paired programming again because they miss the opportunity to learn from another developer.” So ultimately, what they discovered was that self-organizing teams are particularly effective when you have senior developers on them and, also, a lot of the things that were invented were invented for a reason.

Alex: That’s something that’s always fascinated me about organizations. We look at them, we mock them, but the reality is it’s kind of difficult to take billions of dollars and turn it into slightly more than billions of dollars. Programmer anarchy really speaks to this notion that a small group of self-organizing folks – I’d almost look at it as this notion of a strike team –you know, in military terms can just go in. A really good strike team, maybe of ten people, can clear an entire skyscraper, right, floor by floor. It’ll take a good one to do it, the most senior, most agile, ninja-level skills to do that, but there’s no way that even the best strike team in the world can take a block or a city, for that matter. That’s where you need an army. And I think that’s what we’re looking at here with programmer anarchy is it works just fine when you’ve got a strike team, but they’re not gonna be able to build a giant system. It’s just not possible because it’s too big for them.

Remy: I think that is an excellent point to wrap up this episode on. I think we’ve got some grist for the mill for some future episodes. Jane, I want to thank you for hanging out with us today on this podcast. I communicate with the writers mostly via e-mail, so it’s kind of a nice treat to actually get to hear one of the voices on the other side of that e-mail chain.

Jane: It was my pleasure.

Alex: Definitely, and hopefully you can join us for one of the Radio WTF things that I’m sure Lorne is working on and will have for us soonish.

Remy: Yeah, maybe the person who’s the editor of the site should contact Lorne and make sure that that’s going into progress. That’s, uh…

Alex: Remy, this is how you’ve ruined the site.

Anarchy for Sale.
[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!