Unravelling the monoglot monopoly

Podcast Transcript

Mike Mason:

Hello and welcome to the Thoughtworks podcast. My name is Mike Mason and I am one of the hosts of the podcast and I'm here today with Rebecca Parsons, who's the CTO of Thoughtworks. Hello Rebecca.

Rebecca Parsons:

Hello Mike.

Mike Mason:

And I'm also here with Evan Boucher, one of our technical principles from Australia. Although I mean we changed job titles all the time. And you still technical principal or is it some other?

Evan Bottcher:

No, that'll do. I take care of engineering across Australia at the moment.

Mike Mason:

Excellent. So we're here in Shenzhen, China. We've been locked in a room together. We're part of the Doppler group that creates the Thoughtworks technology radar. When we do the radar, people suggest technologies that are moving and interesting now, or they suggest techniques, things in a positive light or possibly in a negative light. And one of the things that was put up this week, started off as node for all the things, which was, I guess you could call it a technique or a set of architectural decisions where organizations are choosing to use a node and JavaScript throughout their technology stack because they feel that coalescing on that one specifically, the language choice around JavaScript will provide them with a productivity benefit. And I think we talked about that whole node for all the things for a little while and ended up with a different name or monoglot monopoly, which I believe came from Johnny LeRoy because he's our department of naming department. And so we talked about monoglot monopoly.

Rebecca Parsons:

And unfortunately while that's awesome alliteration it's actually a very bad name because it's repetitive. Monoglot means there's only one and monopoly means there's only one. But the point is, what we were trying to say is regardless of what the language is saying, you're going to use only one language, exactly one language, is an anti-pattern. You don't get the level of efficiency that you're looking for. Even though it's a popular notion in many of the enterprises that we work with.

Evan Bottcher:

So in a past issue of the radar we, we blipped an item called polyglot programming. It's kind of hard for me to say today and polyglot programming is the idea of making a selection or making a choice of language and even the technology around that language that fits the problem in a really good sense in a particular context. So rather than forcing down a single path, then you'll actually use the right tool for the job and see a wider degree of languages and technologies in use.

Rebecca Parsons:

The problem with that is developers always love to try new things and as we've seen in microservices where you have dedicated long running teams creating their own microservices in the desire to give teams autonomy, which we're big fans of pushing decisions as close to the people that those decisions impact as possible. Many organizations have found that they get an excessive proliferation of technologies and while we clearly think one is bad, 45 is probably not a good number either. And so we want to try to explore the idea of how does an enterprise start to think about what's the right number? How would we get there?

Mike Mason:

I mean there's examples of this in the past I guess with for example, I know at Google their internal choices, they had maybe two or three language choices. Actually, I'm not sure what the number was, but there was certainly kind of probably C++ and Python and maybe something else. And if you chose one of those languages, I think you actually had to choose one of those languages, that the trade off was because it was an official Google language. You got support across the Google platform for it. So if you built something in that language choice, you got scalability and reliability and all the other nice ilities that the Google platform itself was providing for you.

Evan Bottcher:

And so this is a recurring theme and it is very relevant. Like Rebecca said, we're seeing this out of this rise of organizational structures that are pushing more autonomy out to teams and we are having to answer essentially what's the modern version of governance, the right type of lightweight governance to allow people to make sensible choices and choose things that are going to be highly productive. The negative side of working in a place that's got too much technology sprawl is that you really can't be really good at a wide number of things and it stops your flexibility of people moving between projects and platforms and causes a lot of pain.

Mike Mason:

I mean, on that topic of moving people between projects and platforms. I guess I'm curious, I mean, it makes sense that somebody would know a particular set of languages and tooling and if you move them out of their sweet spot, they wouldn't be as effective. But surely they would be able to come up to speed in that different piece of the organization using a different technology stack. So is that just a red herring, that argument that someone would be more efficient or everybody's got a little cog in the machine and we can move them around more easily if everybody needs to know the same stuff?

Rebecca Parsons:

Well I think it's a matter of degree. If you're skilled in an object oriented language and you understand the object oriented paradigm moving from a one OO language to another is relatively simple and yes, you need to learn the framework and the idioms that are more common in that language ecosystem. And it really has become language ecosystems now as opposed to just a programming language. But if you start to say, well, we're going to have a combination of a dynamic on typed language and an object oriented language and a lazy functional language and let's tack several different language families, I don't want to use paradigms. There's another podcast in the series that talks about exactly that. But the more you get that intellectual sprawl, the harder it becomes for any individual to develop any reasonable amount of skill. And one of the scariest programs I ever looked at was an individual I worked with who was incredibly skilled in Fortran.

Rebecca Parsons:

He was an electrical engineer, was working in device simulation. Fortran at that time was absolutely appropriate language choice. He moved to another organization that only wrote in Lisp and this gentleman wrote Fortran code in Lisp syntax because he just didn't quite get it. And so that's really the problem that you run into. Good developers do have the ability to move from language to language, but there is a limit and I think that's what we're really talking about on the other end. One is not the right number but neither is 45 and how do we go about governing that? One of the things that we've seen work in that governance question, we have this notion of our own Technology Radar, but we encourage organizations to build their own radar, to get the decision makers and the users in their technology organization together and talk about what should we be using? What should we be starting to phase out? And part of that governance mechanism can in fact be, we're going to impose the moral equivalent of WIP limits in each one of those spots to say, okay, well maybe it's not one, but please pick three or five depending on what the application is, how large the organization is. And so there are techniques that can allow you to balance that proliferation while still allowing teams to make their own decisions and give them some level of autonomy.

Mike Mason:

And I know Evan, you worked for an Australian client who I keep trotting out as an example for how to do things well and you know, they had elements of why we call the Spotify model working for them with lots of stuff going on and maybe more encouragement of collaboration and sort of spreading best practice rather than decision making by diktat. What was the situation there around technology choices?

Evan Bottcher:

Well there was a high degree of autonomy and there was a lot of choices. It's been a while since I've spent a large amount of time there. But I tell the story quite a bit of some of the decisions we made around technologies, and this isn't just language, this is any layer of the stack where I've always sort of said there's really three main slots if you like, for a technology choice. There's our default, our good default, we know how to do and you would pick it for every new thing that you're going to do by default. There's the one that we're getting rid of because it's no longer very good and it's been supplanted by the default and there's the one we're doing an experiment on and generally not much more than that.

Evan Bottcher:

That was a reasonable way of managing that work in progress limit. And that if you're saying that we've got a new default, then you're actually committing as a team to replacing over time the parts of the deprecated, the technology choices that are no longer the right thing. I think this is a good guiding, having a visible metaphor like the Radar. Other places I've seen technology playbooks like that have pretty much put in place the agreement on what these things are is great because we can share that and then you can say, okay, maybe there's a need to invest some engineering effort in making those things highly productive. Like make sure there's good tools and good deployment technology and good observability and good run time controls for this more limited set of technologies but not necessarily limiting that to just a single technology like we might've done in the early 2000s.

Rebecca Parsons:

Well, and the thing I like about that model is it does recognize that there may be aspects of a system, maybe it's because of deadline pressure, maybe it's because of the nature of the problem that there is in fact a different stack, a different language environment that might be more appropriate. And when I've heard you talk about that particular client before, the emphasis is on making it easy to do things the way everybody else does. If you do choose to go a different path, you have to make sure you reflect the observability and the monitoring standards. And you're probably going to have to implement those all yourself because it's not part of the standard. So it's okay, but it's okay within a context because we're not going to say, yes you can just throw some random new language into the mix. We want you to instead say you can use a new language if you really think this is the right thing to do, but to operate in our ecosystem you have to adhere to our language or our adhere to our logging standards, have the right kind of monitoring available and probably you have to be able to explain why this is the right choice for the organization rather than just participating in resume driven development, which unfortunately we also see a fair amount of.

Mike Mason:

And I think from my perspective, that's often a difficult thing for an organization to kind of self assess. Where are we at? And I mean Marlin Fowler talks about you must be this tall to ride in term for microservices. You need to have great dev ops culture in place in order for microservices to work for you on a bunch of other things. It sounds like in this case as well, a team needs to be pretty competent in order to make an active decision to move away from whatever the defaults are and onto something else. But the problem is that we all think we're above average drivers and it's actually quite difficult to self assess where are you really at? One of the other aspects that we talked about was kind of the competition for talent out there in the world right now and appearing to be on the leading edge of technology choices maybe can attract people to the organization. Like does that have an impact here?

Evan Bottcher:

By my observation, I think that sometimes the choice of more language choices and technology choices and increased autonomy is a very attractive thing for engineers to come into an organization. I do think there's a bit of a curve in place where sometimes in order to bring an influx of new talent and strong engineers, you do need to essentially allow for a wider degree of technology choices and it seems like there's a bit of a path that organizations go through and then rationalize and actually start to focus that energy more towards solving real business problems and functional problems by making a few set of technology choices much more productive.

Mike Mason:

So around the topic. What's the advice that we would ask listeners to take away with them?

Rebecca Parsons:

Well, I would say again to restate what kind of feels obvious, there's a whole lot of numbers between one and 45 and while we agree that 45 or 57 or any large number is too big, one is too small. And we need to enable organizations to figure out for themselves at this particular point time with the particular people that I have with my aspirations for growth, what that right number is, and then put in place the techniques and the guard rails to manage to that number to maximize the autonomous decision making while minimizing the drag that can result from too much variety.

Mike Mason:

Well Rebecca, Evan, thank you very much for joining me. This has been the Thoughtworks podcast. Please do leave us a star rating or a comment on whichever podcast platform you're listening to this on because that really does help people find the podcast and tune in next time for more info from Thoughtworks.