Has development gotten simply too complex?
In this episode, we talk about Facebook’s plan to shut down its Facial Recognition System, and a mass firing at a Russian payment services company fueled by AI productivity measurement tools. Then we speak with Scott Carey, enterprise technology journalists at InfoWorld, about how the growing complexity of modern software systems might be “killing” software developers.
Saron Yitbarek is the founder of Disco, host of the CodeNewbie podcast, and co-host of the base.cs podcast.
Josh Puetz is Principal Software Engineer at Forem.
Scott is a technology reporter at InfoWorld, where he covers software development and cloud computing.
[00:00:10] SY: Welcome to DevNews, the news show for developers by developers, where we cover the latest in the world of tech. I’m Saron Yitbarek, Founder of Disco.
[00:00:19] JP: And I’m Josh Puetz, Principal Engineer at Forem.
[00:00:21] SY: This week, we’re talking about Facebook’s plan to shut down its facial recognition system and a mass firing at a Russian payment services company fueled by AI productivity measurement tools.
[00:00:33] JP: Then we’ll speak with Scott Carey, Enterprise Technology Journalist at InfoWorld, about how the growing complexity of modern software systems might be “killing software developers”.
[00:00:42] SC: And I’ve started to wonder whether we were coming to the precipice of that now where there’s just too much. And there is no way to decide the best way forward.
[00:00:52] SY: So this week, we’re starting off with a huge story about the artist formerly known as Facebook. Oh yeah. By the way, Facebook now has a newly named parent company called Meta. Very original. Yeah. So you’ve probably seen a lot of pieces this week about how Facebook is making a lot of different kinds of pivots in conjunction with its new Meta rebrand and focus on what Zuckerberg is calling “the metaverse”, hence Meta. There is a really great piece in the New York Times by Technology Reporter, Kevin Roose, titled, “The Metaverse is Mark Zuckerberg’s Escape Hatch” that talks a lot about this, which we’ll put in our show notes. So the new Meta change to Facebook, which was announced this Tuesday on the Meta blog, is that the company will be shutting down Facebook’s decade old face recognition system. This means that people will no longer be automatically recognized in photos and videos. And the company says it will also be deleting more than a billion people’s facial data templates that the company uses to identify people. This shutdown will also eliminate Facebook’s automatic old text, which uses sophisticated AI to create image descriptions for the blind or visually impaired. In the post, the company says, “We need to weigh the positive use cases for facial recognition against growing societal concerns, especially as regulators have yet to provide clear rules.” More than a third of Facebook’s daily active users had opted into this face recognition system according to the company. This of course all comes on the heels of the explosive congressional testimony. A former Facebook employee turned prominent whistleblower, Frances Haugen, and the load of Facebook internal documents she leaked, which we went into depth last episode. So you should definitely listen to that one. So Josh, what do you think about this whole facial recognition feature just being removed?
[00:02:51] JP: It’s kind of like the Facebook, I’m sorry, it’s kind of like the Meta apology tour lately, isn’t it? The timing is suspect. Right?
[00:03:00] SY: It feels very suspicious. I’m like, “But why?” Here’s the thing. I feel like it’s actually a useful tool. Right? I really appreciate, I don’t use Facebook, but on Apple images, like iCloud photos, it’s really helpful when it recognizes faces. And I can search by like Rob and I can search by my mom. And you know what I mean? It’s really useful. So like it’s very beneficial. I can see that. I didn’t even think about the accessibility angle. I think that’s really helpful that makes it really accessible to people who can’t see or otherwise are visually impaired. So it really feels like it’s a feature that had purpose. Like it’s not just, “Oh, we’re collecting all this data to give to our advertisers. He, he, he!” You know what I mean? It feels like it would actually be beneficial.
[00:03:43] JP: Well, that we know of.
[00:03:44] SY: That we know of. That’s true. That we know of. That we know of. It could just be an excuse for other reasons, but I can see it being an issue where users feel like they are now missing a feature. Like, “Oh, now I have to tag all these photos myself.” I can see users being annoyed by it. And so it’s not the kind of feature that I would think Facebook would rip out. And I am very suspicious as to why.
[00:04:09] JP: Yeah. I mean, I kind of welcome it, like Facebook having all of this facial data is problematic to say the least. I could definitely envision a situation in which foreign government says, “Hey, Facebook, you’ve got facial data. Why don’t you give it to us?” Or something terrible like that. So I appreciate that they’re getting rid of it. I mean, the blog post is really, God, it’s killing me to say this, but like it’s really well written and thoughtful about how they’re saying, “Yeah, there are benefits to having the facial data for taking pictures and logging in, but we think the societal harm or potential for harm outweighs it. And that’s great, but it’s Facebook. And so I’m just like, “Well, okay.”
[00:04:53] SY: Did they hire someone new? Is this the same company that we’ve had for years?
[00:05:00] JP: All it took was a rename. Meta Mark Zuckerberg is totally like into privacy now.
[00:05:06] SY: You know, there’s a lot in a name. That must be what it is.
[00:05:10] JP: Maybe we shouldn’t be so suspicious.
[00:05:12] SY: They’re a whole new company now.
[00:05:13] JP: Literally. Not literally, but the renaming and the pressure on them from Francis Hogan I think is affecting some change. It’s affecting a lot more change than I thought was ever possible. So good.
[00:05:28] SY: But do you feel like it’s because they had a change in heart where they’re like, “Now we’re going to try and be more active and take these steps”? Or do you feel like they’re trying to kind of get ahead of any regulations?
[00:05:39] JP: Oh, no! I think they’re totally trying to get ahead of any regulation.
[00:05:41] SY: Okay. Cool.
[00:05:42] JP: I think they’ve been hauled into how many, four or five congressional hearings.
[00:05:44] SY: We got to do something.
[00:05:47] JP: And now there was a whistleblower with actual receipts to show the public about what’s going on. I have no doubts. This is a strategic move to say like, “Okay, what things could we get rid of that are kind of dicey, but aren’t going to impact our bottom line?” Because think about it. The facial recognition stuff, they’re not making money off of that. Right?
[00:06:08] SY: Yet. Yeah.
[00:06:09] JP: They said they haven’t sold this information. They don’t put ads on facial recognition yet. So I think this is something that is one of the few problematic things Facebook does is they don’t monetize so they could get rid of it. Yeah. It just sounds suspicious of like his company.
[00:06:28] SY: Yeah. I think the strategic kind of getting ahead of any potential issues with the law, I think that’s probably what’s really going on. And I mean, to me, the part that was most surprising wasn’t just the getting rid of the feature. It was deleting the data.
[00:06:44] JP: Yes. Yeah.
[00:06:45] SY: That’s what really surprised me.
[00:06:46] JP: Exactly. Facebook is a company that holds on to data forever.
[00:06:50] SY: Yeah, exactly. They could have just said, “Oh, we’re going to stop using this. Look at us. We’re doing good.” But they actually said like, “We’re going to stop and then we’re going to also fix the last 10 years of getting rid of all that data that we had,” which was very surprising to me.
[00:07:03] JP: That is really, really surprising.
[00:07:05] SY: Well, good for them, good for us. That’s definitely a win for privacy. Hopefully, we’ll maybe get a couple more pleasant surprises like that. That’d be nice.
[00:07:30] JP: Speaking of other dubious uses of AI and people’s data Xsolla, the Russia payment services company, fired 150 of its employees in one fell swoop. Now the interesting thing about this firing is the reason the CEO and Founder Aleksandr Agapitov gave for the mass terminations. A translation of a leaked email he wrote to employees says, “You received this email because my big data team analyzed your activities in Jira, Confluence, Gmail, chats, documents, dashboards, and tagged you as an unengaged and unproductive employee. In other words, you are not always present at the workplace when you work remotely.” He later gave an interview and explained, “The performance rating system was implemented in early 2020.” The company measures its employees’ efficiency on a 100-point scale based on 30 characteristics, which include writing and reading articles in its internal wiki, creating closing task tickets as well as dashboard activity and participation in internal meetings. He cited Xsolla’s slower growth down from a high of 40% over the last six months as a deciding factor to reduce staff. In an interview with Russian gaming website DTF, one of Xsolla’s employees who was laid off said, employees had no idea about their productivity rating and the company had planned on introducing a transparent rating system, but it was put on hold. Saron, how has your engagement in Confluence and Jira really? I feel like if this is what you’re going to be rated on, a lot of us are in trouble.
[00:09:00] SY: Yeah. I mean, this is the kind of thing where, I primarily work for myself and I work with you and our producer, Levi. So I don’t have a lot of opportunities to show my activity. I do things mostly solo on my computer, and that’s kind of it. But when you’re on a big team and he fired 150 people, what is your day like? Are you constantly on Jira and Confluence? Is that a normal expectation?
[00:09:26] JP: It possibly is. I just checked the latest information I found pre-layoffs that Xsolla had about 360 employees.
[00:09:33] SY: Oh my God! So that could be half their team.
[00:09:36] JP: This is a big deal. And it definitely seems like it was motivated by their slowing business, but still. Yeah, I’ve worked in larger companies where employees are very specialized. And so you might have a customer support person that’s just responding to tickets in a help system all day long. Or as a developer, if you’re in a really specialized position, you might be just taking a ticket out of Jira, completing it and going on to the next ticket. You might not have a lot of the role juggling that those of us that work for smaller startups. It seems like we do every job simultaneously a lot of times. So I can definitely envision companies where it would be possible to put this kind of monitoring in place, but it seems really harsh, especially if you don’t know about it ahead of time. Right?
[00:10:32] SY: Yes. It feels harsh if you don’t know about it ahead of time, but I also feel like even if you know about it, you’re now optimizing your work around engagement versus productivity, because now I’m like, “All right, have I checked in to Jira today? Have I been active in chats? Okay, let me make sure I get my five posts in Slack today.” You know what I mean? There’s this law. I can’t remember what it’s called, but it’s basically saying, “Be careful what you measure because what you measure will end up being like the goal and the goal isn’t to chat.” The goal is to do your work. But if you’re only measuring chats, then you kind of end up measuring how chatty is your employee? That’s what it ends up becoming.
[00:11:12] JP: Right.
[00:11:12] SY: So I get that these things are proxies to what you really want to know, which is our employees being productive, but I don’t feel like they’re the right proxies. And I think that’s tough, like when you’re working remotely and you don’t have a culture of working remotely, I get the fear of like, “Oh my God! Is anyone even paying attention? Are they even there? What are they doing” I can see from the manager's perspective, that's kind of like fear, but I think that’s where trust comes in. I think ultimately you have to trust your employees and I think ultimately you need to agree on what does success look like in that role. And I don’t think success should be how many times did you check your email. Success should be how many features did you deploy. Right? How many bugs did you squash? Those are things that we should be measuring. So I just think it’s just not the right strategy.
[00:12:00] JP: Yeah. It really sounds like though they were just over a barrel and I don’t really want to defend this company and this practice because this is pretty terrible. And I would hate to see other companies adopt this as a way of getting rid of workers, but when you look at it, they had 300 some employees and they cut 150 of them. There’s not a great way to do that. Right? You can hook it up to performance measurements, but at the end of the day, if you’re firing every other person in your company, that’s rough. I mean, that’s not great. What I’d be more concerned about is like going forward, will Xsolla and other companies continue to use this metric? Right?
[00:12:37] SY: Right. Right. That’ll be really telling. Yeah.
[00:12:39] JP: Yeah. And I agree with you. You get out what you measure.
[00:12:42] SY: Yes.
[00:12:43] JP: At the end of the day, what’s your job? Is it reading stuff in Jira and Confluence? Well, okay then measure that.
[00:12:50] SY: Yeah. I think to me, what really got me about this whole story isn’t even the fact that they’re doing monitoring. It’s the email that Aleksandr sent. I have to quote this email. So in the email, he writes, “Many of you might be shocked, but I truly believe that Xsolla is not for you. Nadia and her care team partnered with seven leading HR agencies, as we will help you find a good place where you will earn more and work even less.” Is that not the pettiest thing you ever read?
[00:13:20] JP: It’s some!
[00:13:21] SY: Is that not the pettiest thing?
[00:13:24] JP: Well, you know, a lot…
[00:13:29] SY: But that’s not it. Let’s finish this off. Here’s the last sentence of this email. He writes, “Once again, thank you for your contribution. If you want to stay in contact with me, please write me a long letter about all your observations in justice and gratitude.”
[00:13:44] JP: Oh my gosh!
[00:13:45] SY: Those are literally the final words of the guy who just fired you.
[00:13:49] JP: Okay. Ouch!
[00:13:53] SY: I was like, “Oh my goodness!” Wow! This is pretty bad.
[00:13:56] JP: Maybe falling back out on an algorithm for this particular founder is a good thing because he doesn’t have a way with people, right? Oh, that’s rough. That is really rough.
[00:14:05] SY: Yeah. That is really rough. It’s better not to get fired. And to get fired with those words? Oh my God!
[00:14:12] JP: My heart goes out to everyone at Xsolla that was laid off and I hope you all find better places to work.
[00:14:18] SY: Yeah. Well, you can earn more and work less. I mean, that is the dream ultimately. Right?
[00:14:23] SY: Oh my God, gratitude. It’s like of Brené Brown.
[00:14:28] SY: So coming up next, we speak with Scott Carey, Enterprise Technology Journalist at InfoWorld, about how the growing complexity of modern software systems might be “killing software developers” after this.
[00:15:01] SY: Here with us is Scott Carey, Enterprise Technology Journalist at InfoWorld. Thank you so much for joining us.
[00:15:07] SC: Thank you. Nice to be here.
[00:15:09] JP: So you had an article this week in InfoWorld, entitled “Complexity is Killing Software Developers,” which caught our eye. Can you talk a little bit about what the piece is about and what led you to write it?
[00:15:21] SC: Yeah. I’m really glad that I haven’t been accused of clickbait. Yes, it is an eye-catching headline, but it’s also one that needs to do what it says on the tin. Otherwise, you get a lot of backlash and obviously I’ve been doing this long enough to know what that can feel like, but so far so good. What happened was over the last two years, since I really deeply started covering the job of software development and also the shift that cloud computing has brought upon that discipline, I kept coming across this idea of complexity. Everyone I spoke to would mention just the growing complexity of what they had to do if they moved over to this cloud native development mode of doing things. And also, I spend a lot of time for my sims talking to software vendors and vendors are all very much on this because they see lots of dollar sign opportunities here because of simplifying that complexity could be a very viable business strategy. And I’ve started seeing that a lot in the product announcements that I would cover from AWS and Microsoft and Google. It really started shifting away from more and more things that you can consume from them to more packaged solutions, where they were like, “We can give you these six things in a bundle that are going to help you solve X problem.” And that’s obviously a natural progression of their business model from serving developers to now serving enterprises. But I thought it was a fascinating kind of shift in the way that they were talking about cloud services and software to these more simplified abstracted solutions. So I went out and started talking to a bunch of people and I tend to talk to people who are a little bit higher up the stack. So the piece is obviously about developers, but I tend to talk a little bit more to their bosses, the software engineering managers or CIOs. And those types of people are extremely concerned by this problem. They want to try and simplify the job for the developers because they want them to be working at high velocity and they want them solving problems for customers, and they want them doing what they do best rather than worrying all the time about whether they’re using the coolest new technology or whether they’re doing things like coming out of the open source community and just spending too much time worrying about the cutting edge and less time worrying about what they’re actually paid to be worrying about. So that was where the idea came from and I started trying to pick away at that thread.
[00:17:55] SY: So this critique that software is getting too complex, and to the detriment of development and developers, it’s not necessarily a new idea. Even your article starts out with that famous quote from Microsoft veteran, Ray Ozzie, where he said, “Complexity kills.” So what is it about our software ecosystem today that made you feel like it’s particularly relevant to write about?
[00:18:19] SC: Yeah. This is the thing. With complexity is that you can go in a lot of different directions. And I think the complexity that Ray Ozzie was talking about was the complexity inherent in a code base. And I think that this is something that if you go back to Steve Jobs and the way he used to think about software, that he was very strong on. It was about simplifying that for the developers and in the mobile era in particular, that was definitely the way that a lot of companies were thinking is, “How can we simplify this to just give you a place to build applications and deploy them onto the app store?” And that went through that cycle of simplification. With this piece in particular, the part that started to emerge for me in terms of where that complexity actually lies is less in the code base itself and more in the fragmentation of the tools that were available to developers. I quote him extensively because he’s one of my favorite people, but Steve O’Grady over at RedMonk spends a lot of his time thinking about this stuff and he’s written a few great blog posts just about the level of fragmentation of cloud services available to people and just how like baffling that can be for a developer who is starting from scratch. You talk about these greenfield applications, even within a big company, I used to cover banks and financial services a lot and they would want to build a new cool FinTech, like app inside their own four walls, and they would send off a team to do that and allow them to use whatever they wanted to use. What occurred to me was just the amount of options that they had in terms of how they wanted to build that was truly, truly baffling and quite overwhelming. And I’ve started to wonder whether we were coming to the precipice of that now where there’s just too much. And there is no way to decide the best way forward in a way that maybe 10 years ago you could do with Heroku where you could just say, “All right, we only want to build one thing. We’re just going to build on Heroku because they’re going to simplify the hell out of this for us.”
[00:20:19] JP: So on the surface, it would seem like having these choices would be a good thing. And I’m wondering if you could give some examples of how we’re hurling more towards detrimental complexity and concretely what that means for developers.
[00:20:33] SC: Yeah, I completely agree. I mean, this was the thing that I wrestled with throughout the entire reporting process of this story was, is it a net good or net bad thing that developers have all this choice now? And frankly, I couldn’t decide for myself. Basically, I just passed as many people as possible what they thought and the response generally was yes, we have tipped over the precipice of all this choice being useful into an area where actually it is detrimental. I think that another guy that in the industry that you might know, a guy called Corey Quinn, who works for The Duckbill Group, he’s generally more of an AWS billing expert, but he’s also very outspoken about AWS in general. And one thing he likes to joke about is the fact that there’s like 18 ways to deploy a container on AWS. And that to me just seems insane if you’re just trying to solve a business problem, which frankly most developers are paid to do and trying to decide which one of those 18 ways to deploy a container just seems like not the best use of their time. And a lot of the people that I ended up talking to, they said this, the exact quote from Nigel Simpson who used to work at Walt Disney is like he saw a lot of his developers who were moving from three-tier architecture over to microservices, they were just getting caught in the headlights. They just didn’t know what the best thing to use was and they were wasting so much time trying to work that out that they weren’t actually doing what they were meant to be doing. And obviously, constantly learning is a hugely important thing for developers to do. But if you don’t know where to start with that, we’re into a world now where that is less just the natural progression of the craft, and actually it becomes something that there were a few developers I spoke to that actually just put them off the job totally because they were like, “Every time I learn something, it’s immediately of no use because the zeitgeists has moved on and they were getting very frustrated by that.” So that was what I was seeing with this tool and complexity is it was just happening at such speed that many, many developers just didn’t even know how to keep up.
[00:22:47] SY: And there’s also this idea of essential versus accidental complexity, right? The intention behind it. Can you tell us a bit more about the difference between these two things and why we might be going possibly in the wrong direction?
[00:23:01] SC: Yeah. I loved that. I found that very useful when I was trying to work out how I felt about this topic. And it’s a guy called Justin Etheredge. He works for a software agency, like consultancy called Simple Thread. He wrote a blog post a few years ago, basically with the same title, “Complexity is Killing Software”, which is what kind of brought him to my attention. But he talks about, and this goes back to your first question, he talks about the fact that software. Development by nature is a complex task. The job is a complex one. The problems that people in those jobs have to solve are difficult. If you’re working at a bank and you’re trying to pull together all of these things to put out a consumer-grade banking application, that’s a complex task. And that for him is essential complexity. That is just the complexity of the job, and that is what developers frankly are paid very well to do is to solve those problems. Accidental complexity is where you start getting in your own way and layering on new levels of complexity onto that already existing complexity. And this is where the fragmentation of the tooling comes in. This came up three or four times from people I spoke to is this developer determination to reinvent the wheel over and over again, even when there’s a wheel sitting right there in front of them on Stack Overflow, that they can just kind of pull in. And that seems to be the area where a lot of development managers and engineering managers are trying to get their developers away from. It’s trying to let them solve the problems that are essential to their business, but stop like accidentally making your job more complex by pulling in things that you don’t need to, if that makes sense.
[00:24:43] JP: So you talk about in the paper the downsides of having so much choice, and that reminded me of the Barry Schwartz book, The Paradox of Choice. Are there similar parallels? Schwartz’s book was obviously about consumers and all the anxiety they face deciding among different products in a retail environment. There a similar parallel to be drawn for software developers, even though they’re not exactly like buying things in a store? But is that anxiety there? Is there any way to reckon with that?
[00:25:15] SC: Yeah. I think this is the direction that we’re starting to see from the vendors is that they are maybe starting to reckon with this realization that there is too much choice on the shelves and that they are starting to now package things up in a way that makes it easier to consume their services. So they do this in a couple of ways. For the hardcore developer, they tend to focus that on managed services, so managed databases. A lot of companies are realizing now that they don’t need to manage their own MongoDB database. They don’t need to manage their own Kubernetes right down to the bare metal because the vendors, depending on what you’re using it for, can do that for you in a way that will cost you money, but probably will cost you less money than if you were paying developers full time to do it. The other side is that they’re really concentrating on industry verticals. This is something that you’ll see a lot of from the big three cloud providers is that they all say, “You’re a health care company. Here are the 12 services that we provide that can get you up and running in the cloud as a healthcare business based on patterns that we’ve seen tried and tested by other healthcare companies in the past.” And I remember Steve O’Grady also like in one of those blog posts saying about there was too much on the shelves and obviously the original cloud era was we’re going to give you every possible option that you need to build applications and you can choose. And he’s now saying that that was the first era of cloud and the way that O’Grady sees it is that we’re now coming into the one where abstractions that are built on top of those primitives is going to usher in the next era of cloud. And that was something that came up a few times in conversations. My colleague Matt Asay as well, who works at MongoDB now, he said a very similar thing after Google Cloud Next a few weeks ago where he said that the second era of cloud would be defined by simply being more boring. It’s lots of cool things being pronounced the world and now it is how can we simplify this in his words, which is very Matt, “How can we make it more boring?”
[00:27:24] SY: So how does this plethora of choice, how does that lead to building more and more internal platforms? And why might that be a bad thing?
[00:27:32] SC: Yeah. The internal platform is an imperfect solution to a growing problem. And as I define an internal developer platform, it’s basically a company that has wrestled with this problem and then they’ve realized that they should build an internal portal. Spotify famously have one that they open source backstage. And it was basically like that’s create a catalog of tooling and templates for our developers that they know are a part of our internal platform. So they don’t have to go off and wrestle with that big catalog of choice on the AWS console. And then that grows and grows and grows to that internal platform team then also being responsible for making sure that your Docker image is secure and that the way that you deploy to Kubernetes is there’s just one singular golden way to do that. And if you need to veer off it for whatever reason, you go to them and you explain to them why that is and then you have to have a robust conversation about why your way is better than their way, but that’s been this emerging model that I’ve seen come out of companies that are trying to wrestle with this complexity issue. The problem with it is that the only companies that I see in successfully pull this off are the ones that have thousands of brilliant developers. So it’s Spotify, it’s Netflix, it’s Yelp. It’s all these kinds of cloud native companies that are very, very engineering focused. They have the ability to do this well. I have yet to see it deployed a more traditional enterprise or an enterprise that is adopting cloud more recently over the past couple of years. So a bank or an airline or a retailer, I wonder whether an internal platform is too much of a culture shift for them to be truly successful, but it is something that I'm keeping a close eye on.
[00:29:29] JP: So obviously, many of these technologies bring really great things for developers, but we’re struggling with the complexity. We’re struggling with the choice. Sometimes we’re struggling with just saying, “Forget all of this and building our own internal platforms.” Do you think there is a solution to being able to take advantage of the breadth of choice of technologies without losing control and losing faith basically to complexity?
[00:29:57] SC: I’m skeptical. I think it’s an interesting question, and it’s definitely not one I can answer because like every software vendor on the planet right now is trying to answer that question. They’re trying to work out if they can solve this problem in a way that is going to make them billions and billions of dollars.
[00:30:17] JP: Exactly.
[00:30:18] SC: And very recently I saw VMware with Tanzu, which is their cloud-y part VMware and they are really focused on this and they released a new platform recently which claims, it’s early days, it’s only in beta, but it claims to be able to help you manage all of this complexity across various environments. And that seems to be the direction of travel for a lot of these companies. But actually doing that in practice is going to be extremely difficult because the genie’s out of the bottle, like developers are used to being able to assemble applications in the way that they want to. They’ve been empowered to do that. And so bringing that back into a Heroku style platform as a service, I don’t really see that happening, but I don’t know what the alternative is. It’s a really interesting challenge. I think that it will be a slower evolution of how developers work. And I do think that there will be more abstracted services, more packaged services used. But as I said, like the genie’s out of the box. So I think that developers are used to working in this way and it’s going to be really difficult to stop them doing that.
[00:31:33] SY: Is there anything else that you’d like to talk about that we haven’t mentioned yet?
[00:31:37] SC: I would love to hear what you two think about this. Is this something that resonated with you? Did you think that, yeah, the job of the software developers become more complex? Or did you think that actually you’ve just been doing things this way and it’s not really a problem?
[00:31:52] SY: I think for me, the conversation we just had about the paradox of choice specifically in terms of, to me, it’s the fear of doing it wrong. I think that because there are so many options and everyone has a hot take and there’s so many new technologies coming about and there’s so much, and there continues to be more and more. And I feel like there are fewer and fewer standards because there’s so many ways to do it and everyone is telling you that this one is better. And to me, it just feels whenever I start a new project, I go, “Oh man, I hope I’m picking the right foundation.” Because once you pick that text, that it is very hard, you have to change your mind. So for me, the complexity and the overwhelmingness comes from just that choice, that choice paradox we talked about and just feeling like just, “Oh, man, I really hope I don’t make the wrong decision.”
[00:32:49] SC: Yeah. That’s so good to hear because that’s exactly what I was sort of coming across over and over again. You kind of get pressured into building on Kubernetes, even though maybe that’s not the best solution, because like that’s what, whenever you go to…
[00:33:03] SY: Yes, that’s what you’re supposed to do.
[00:33:05] SC: Yeah, that’s what you’re supposed to do. You’re supposed to build on Kubernetes, but actually in a lot of cases, that probably isn’t an overly complex way of solving a problem.
[00:33:14] JP: Yeah, for me, this article really helped crystallize this kind of feeling I’ve had over the last couple of years at any time anyone’s involved in a software language or a community for any number of years. You get people eventually saying like, “Oh, this used to be so much easier. Back in the early days, all we did was, with Ruby and Rails, we would just start up a do engine and boom, we’re there. And today, you have to pick this, you have to pick that, there’s all these choices. And I always struggle with, is that just nostalgia for when you are new to a language and you maybe didn’t know about all the choices that were there? Or when a language or a framework was new, it didn’t have all the options and bells and whistles. So you really only had one thing to pick? Or is this actually something that’s happening across multiple fronts in software development? After reading the article and our conversation today, I definitely believe the latter. I think it’s not me just being crazy and thinking like, “Oh, things were so much simpler five years ago.” No, they really are getting more complex.
[00:34:19] SY: They actually were.
[00:34:21] SC: Yeah.
[00:34:21] SY: You were right.
[00:34:23] SC: That’s what everyone says. And I really think that it’s probably more cyclical. I think that technology changes and you go through these waves of change where a new way of doing things emerges and let’s just call it cloud native for the sake of simplicity, and all this new stuff hits the market and then I think you go through a wave of simplification of abstraction that we might start to see happen now, but that’s the part, that’s the unknown. That’s the thing that is impossible for me to know looking into the future. But a lot of people I spoke to who have been doing this way longer than I have, they said that that’s the pattern that they’ve seen over and over again is that new thing emerges. It’s very complex. And then that complexity starts to slowly go away. But I do feel that this might be a greater degree of complexity than there was before, but I guess that’s just the way the world works. But imagine how difficult this stuff is for someone new to the industry. Those are the people that I started thinking about where it’s like if you’re sat there looking at this menu of technologies and you’re thinking, “Where do I want to put my back on my career?” I mean, it’s got to be overwhelming, right?
[00:35:37] SY: Yeah, absolutely. Well, thank you so much for being here.
[00:35:40] SC: Thanks for having me on. It’s been a really fun conversation.
[00:35:53] SY: Thank you for listening to DevNews. This show is produced and mixed by Levi Sharpe. Editorial oversight is provided by Peter Frank, Ben Halpern, and Jess Lee. Our theme music is by Dan Powell. If you have any questions or comments, dial into our Google Voice at +1 (929) 500-1513 or email us at [email protected] Please rate and subscribe to this show wherever you get your podcasts.