In this RedMonk conversation, Kelly Fitzpatrick, senior analyst at RedMonk, and Tom Johnson, co-founder & CTO of Multiplayer, discuss the evolution of software development and the importance of collaboration and documentation in enhancing developer experience. Tom shares insights on the challenges developers face today, the need for dynamic tools that auto-update documentation, and the distinction between system diagramming and system design. The conversation emphasizes the necessity of adopting new tools to improve productivity and developer happiness.

This RedMonk conversation is sponsored by Multiplayer.

Links

• LinkedIn: Thomas Johnson
• Twitter/ X: @tomjohnson3
• Multiplayer.app
• Twitter/ X: @trymultiplayer
• Devs Need System Design Tools, Not Diagramming Tools
• Strategies for Managing Architectural Technical Debt that DON’T Work

Transcript

Kelly Fitzpatrick (00:12)
Hello and welcome to this RedMonk Conversation. My name is Kelly Fitzpatrick and with me today is Tom Johnson, CTO of Multiplayer and long time developer. Tom, thank you for joining me on the MonkCast today.

Tom Johnson (00:24)
Thanks for having me.

Kelly Fitzpatrick (00:26)
And Tom, to start things off, can you tell us a bit about who you are and what you do?

Tom Johnson (00:30)
Sure. I’m, my name’s Tom Johnson. I’m the co -founder and CTO of Multiplayer. My background is in software development for over 20 years. Got started in speech recognition and robotics, segued into telecom software. And then when the web became a thing, I worked on building large distributed systems for a number of small companies and large companies.

Kelly Fitzpatrick (00:58)
So you’ve been doing like totally easy things is what I’m hearing. And so Multiplayer is a word that I have heard in many contexts, like first and foremost, like gaming, like I’m a gamer, like I have a book with a chapter on like MMORPGs. So like that’s a word that I am familiar with. You have a company called Multiplayer. I want to hear more about the company and the name.

Tom Johnson (01:00)
Yeah. Sure, yeah. So, so Multiplayer is a company that builds tools for teams that work on distributed systems. And for anybody who, you know, designs, develops software these days, you know that you’ve got these really complex systems and you need a team to work on this stuff together. It’s no longer a solo act, or it’s really hard for it to be a solo act. So there’s, it’s a team sport. And we thought the name Multiplayer, was perfect for this company that we started.

Kelly Fitzpatrick (01:54)
Yeah, and I like that. I agree, like very few people are building things solo these days. And so for folks out there who are not already familiar with RedMonk, our focus is on developers and other technical practitioners. We spend a lot of time talking about developer experience and tooling. One thing we’ve noticed is that building software today is just not the same as it was even a few years ago.

Tom Johnson (01:59)
Right.

Kelly Fitzpatrick (02:16)
Systems are more complex. Developers are asked to do more and more. And while there is a cornucopia, of developer tooling out there, navigating these choices and having to stitch or metaphorically duct tape them together often leads to what my colleague, Steve O ‘Grady, has called the developer experience gap. Tom, you have been in very technical roles for quite a long time. How have you seen things change for developers?

Tom Johnson (02:40)
Boy, it’s different than when I got started. So you could do so much on your own. Systems were a lot simpler. You’d have client server, you have two things. And even before that, you just had desktop software, one thing. So now you have complex platforms that pull together microservices and apps and SaaS platforms and cloud. So you’ve got systems are more complex. They’re also more dynamic, meaning they’re changing more frequently. But on top of that,

You know teams are different. It’s no longer a solo hero developer that does all the things you have specialists DevOps front -end developers back -end developers and even executives and managers are getting involved in the development of software So it’s it’s changed radically since when I started

Kelly Fitzpatrick (03:27)
Yeah, and I would say it’s, I have not been in the software industry as long as you, but I have seen it change drastically, even in the last six years that I’ve been an analyst, much less from when I was actually a practitioner running a test and a release team. And the other thing that just blows my mind is the potential changes in the onboarding of new developers to just the experience of building software today. It is just so drastically different than it was back when I started.

Tom Johnson (03:56)
Sure, it’s so much harder. If you’re a developer coming into a new team, the first question you’re going to ask is, OK, what is your software? And that’s a tough question to answer. Documentation is probably spread out, out of date. You can no longer go to one person to answer the questions anymore. So it’s really a challenge. And that’s one of the things that we’re looking to solve at Multiplayer, make that a lot, lot easier.

Kelly Fitzpatrick (04:22)
I’m glad that you brought up documentation because it means I didn’t have to do it. I’m also a former tech writer. So I tend to be like, let’s talk about documentation. And folks are like, why are we talking about documentation? But you’re already there. And I think that’s relevant to a trend that we’ve been seeing in recent research on developer experience and productivity, which we’ve seen a lot more people talking about both of those things in two areas that we see consistently cited as influential factors in determining developer experience are documentation and technical debt. Does that fit with what you are seeing?

Tom Johnson (04:58)
Absolutely. So developer experience, you know, I sort of think of that as like, how happy are your developers? How productive are they? And, you know, it starts with like having clarity messages coming from above to say what you should be working on clear focus, and to have a clear picture of like what you’re working on, to understand the system

And a big part of that, as boring as it sounds, is having a source of truth, up -to -date documentation about your system and to not have to chase it, to not have to put a lot of manual work in keeping it up -to -date. So we’re trying to fix this problem by letting your system auto -document itself.

using open technologies. So we’re hoping to solve this, take the manual work out of documentation, have a source of truth and have a better developer experience as a result.

Kelly Fitzpatrick (05:54)
Yeah, I love that documentation that is not relying on a human necessarily doing it. Not that you don’t want humans involved, especially at crunch time, documentation is one of those things that often gets dropped to the bottom of the list because there are other fires to put out and it’s something that we need nevertheless.

Tom Johnson (06:11)
Sure. And it comes into play in different phases of development. you want your source of truth to be the thing that you don’t have to manually update because nobody does it well. I mean, everybody’s got horror stories about the diagram that they updated a month ago and it’s out of date and all this sort of stuff. So you want your source of truth to be something that is driven by your system. But you’re right. There is still manual work. If you’re designing something, you’re choosing. like what you intend to change, there’s some documentation there. You need to communicate that. That can be a challenge as well.

Kelly Fitzpatrick (06:50)
Yeah, So follow up question, you’ve recently written about the differences between system diagramming and system design and we’ll link to that article in the show notes. But one thing that caught my eye is your articulation that developers use diagrams as a form of communication. And you’re right, I’m gonna quote this. “Developers often use diagrams to tackle a fundamental communication challenge conveying the complexities of a distributed software system, including its components, dependencies and APIs clearly and effectively to a distributed team,” end quote.

I get, as you argue, diagramming tools might not be the best way to communicate all of this complexity. Can you tell us more about this, especially for folks who have not had time to read your article yet?

Tom Johnson (07:33)
Sure, sure. So humans are visual by nature, you know, a picture is worth a thousand words. With a complex system, it can be easiest to use sort of visual metaphors to communicate, complex sub topics and ideas quickly. So the idea of visualization, great. Diagramming tools aren’t built for system design and system design

incorporates more than just a picture. It’s collaboration. It’s knowing what you’re working on. You have a source of truth and not some outdated thing. Right now there’s just manual work and sort of keeping that diagram up to date. You don’t want that to be part of your sort of design process. And on top of that, one of the things that you do in

in a team is not just sort of look at a diagram for just informational purposes, but you’re frequently debugging issues and you need something that’s like more interactive, more than just looking at a picture. So visualization is good, but diagramming leaves a lot to be desired. It doesn’t solve a lot of the problems that developers and teams have.

Kelly Fitzpatrick (08:49)
Yeah, and I think also in terms of diagramming as we are we are creating a visual image, right, as opposed to we are collaboratively creating the map for a system. I think that’s a slightly different thing. They’re a slightly different project. And I feel like that lack of single source of truth that can kind of come out of it. Like you had you had mentioned like, what is it like to do a diagram and then see that it is updated a month later? I feel like

Tom Johnson (09:04)
Thanks

Kelly Fitzpatrick (09:19)
I’ve done a diagram and it has been out of date the next day. So I feel like the feedback loops and the iteration cycles that we’re seeing today, especially with the architectures that are like in vogue, are really not conducive to static diagrams.

Tom Johnson (09:23)
Absolutely. Absolutely. Static, mean the word static, it’s not, you’ve got a dynamic environment with a dynamic team and a lot of things that are changing that does not connect well to a static diagram that isn’t a file somewhere living and collecting dust. So, that, you know, you’ve got the different phases of development. You’ve got design, development, know, deployment, and then the cycle of that.

happening. you need something that is like source of truth, auto updated, takes the manual work out and allows you to change things and developers need to see diffs and changes, you know, diagramming tools don’t do that. You need to know what the intent is. If you’re making a design, I want to know if I have a thousand components in my system, my feature probably changes one or two or three things. Maybe I’m adding a component, a new service, a new dependency. changing a couple of API endpoints. I need to communicate that to people effectively. And diagramming tools just weren’t built for that.

Kelly Fitzpatrick (10:41)
And then I also feel like anytime you’re, even if you’re changing, you just one or two or three things, the chances of you breaking something and then being able to find what broke, my goodness.

Tom Johnson (10:49)
Exactly. Yeah. Yeah. So in diagramming tools, as a lot of people know who tried to use them for system architecture, there’s a certain point where the number of components and the number of lines between, things representing dependencies, just things break down. You cannot, you no longer see what’s connected to what you no longer understand the dependencies and things. So,

Answering the question like if I change this what will break is Unanswerable, especially when it’s not auto updated It’s probably wrong and what line is this again and it’s overlapping with these 50 other things Like it’s just it’s just tough

Kelly Fitzpatrick (11:33)
Yeah, so we’ve talked a bit about why developers need to start doing system design instead of just diagramming any other thoughts on the types of tools that developers need in 2024 and beyond.

Tom Johnson (11:49)
Sure. So you need a tool that is auto -updating your source of truth, connected to your system, takes the manual work out of collecting and discovering and tracking your system. It takes the work out. So you can see visualizations as a system architecture, you can see the APIs, you can see the dependencies, you can see all sorts of other things. so, know, tooling that allows for that, then, you know, you have something to work off of and you can trust. So that’s one thing. The tool needs to be collaborative too. I mean, we see on Figma and the front end development, it’s like the value of having a tool where people can come together and work together in the same.

stuff. It’s no longer just like a database listing of like the services that I have in my platform, but it’s an interactive set of documents that we can work on together. That’s important for the design phase. And then, yeah, so the collaboration needs to be distributed real time as source up to date. And those are really important things for the tooling for developers now and in the future.

Kelly Fitzpatrick (13:10)
And let’s say someone or some team wants to follow your directive to stop diagramming and start designing and find some better tools to allow this. Any advice on adopting new tools because sometimes the overhead of switching tools can in itself be prohibitive.

Tom Johnson (13:28)
Sure. I mean, that’s a great question because you have this of sunk cost fallacy where it’s like, I’ve got all these diagrams and, you know, I spend a lot of time on this. Let’s just keep going in that direction. I would focus more on like the benefits of productivity and developer experience, developer happiness by abandoning the manual out of dates, you know, troublesome current way of documenting and debugging. And, know,

Use a tool that removes the manual work, immediately increases the developer experience and just embrace that for the future. That is the future. It’s, we are transitioning from manually updated doc system documentation to auto updated with lots of other tooling built around that. You know, you might as well embrace it now, get the developer hours back, get a little happiness up, just do it.

Kelly Fitzpatrick (14:23)
I am all for anything that increases developer happiness. So I think that’s a good aim and maybe worth putting in the time to bring in a tool that maybe can help with that.

Tom Johnson (14:34)
Sure, sure.

Kelly Fitzpatrick (14:36)
So we are about out of time, but before we go, Tom, how can folks hear more from you? Where can folks find you on socials? And are you doing any more speaking we should know about?

Tom Johnson (14:47)
yeah, so you can find me on X or threads as @tomjohnson3. That’s the number three at the end or on LinkedIn is Thomas Johnson. also you can find out more about Multiplayer at Multiplayer.app and we are @trymultiplayer on the social platforms. And, you know, I’ve got, some podcasts coming up. I’m sure we’ll put the post details about that on our site. I love doing podcasts and I’ll be at a couple. Shows too that we will probably promote on the site

Kelly Fitzpatrick (15:20)
Well, Tom, we have loved having you on our podcast. So thank you again for joining us.

Tom Johnson (15:25)
Thank you, thanks for having me.

Kelly Fitzpatrick (15:27)
And again, my name is Kelly Fitzpatrick with RedMonk. If you enjoyed this conversation, please like, subscribe, and review The MonkCast on your podcast platform of choice. If you are watching YouTube, please like, subscribe, and engage with us in the comments.