Design & Develop Distributed Software Better with Multiplayer

Intro

Julian Wood: Welcome to another episode of GOTO Unscripted. We are here in GOTO in Chicago. It's sort of a windy city. There's a little bit of a breeze behind us, but yeah, absolutely beautiful weather and a fantastic conference here in the Willis Tower. I'm joined by Tom. Tom Johnson, you have a storied career about making life simple for developers. A long time ago, things were simple and things were more complex. So tell us the story of what you've been doing and how that translates to what you're doing today.

Tom Johnson: Sure thing. Thanks for having me. It's great to be here. So, where should I start? So I started my career working in machine learning, and speech recognition, segued into distributed systems and telecom, where I sort of grew a fondness for these complicated systems. But they used to be simple. It used to be a kind of client-server. They were just desktop software. There was one thing.

Julian Wood: One base, one thing.

Tom Johnson: One thing. Then there were two things. And then when the internet came around and the web became a thing, you had your web client and your backend system maybe at a web server and then a database. And now you have microservices and you have cloud provider services and cloud things. And you're not writing all the code yourself. So it's become much more complicated to work on these systems, to know what you have, to work with other people, because those teams are now distributed as well, your software.

Julian Wood: It's not just a technical element of having lots of different microservices and clouds but people having to reason about things in their head and organizational complexity. Yeah.

Tom Johnson: Yes. So it's just a whole different world than it was when I got started, and it's been interesting to watch it evolve. So I started a company called Multiplayer, which the goal is to help teams that work on distributed systems. We provide some tooling for auto-documentation, debugging, and, soon, design. So you don't have to be an expert. So you remove a lot of the manual grunt work out of working on distributed systems. And this was sort of born out of my pain working on projects and just over and over and over having to do a lot of terrible grunt work. And finally, I get to try to solve it, which is fun.

Distributed Systems and Simplifying Development with Multiplayer

Julian Wood: Sounds interesting. So going sort of back to that simplistic to become complex, I mean, the reason things became more complex is because we needed to interact, we needed to connect to APIs and queues and cloud providers and all those kinds of things, which was a good thing. So technically, that was a good thing, but I keep coming back to the sort of people's story of that. What are the blockers that people have working in a distributed environment? And you mentioned some things that Multiplayer does, which you're trying to solve, but where do people get into their journey where they realize they've either done the wrong path or they've picked something wrong or they need to retrofit and re-document or reply? What are the mistakes people make, and what can they avoid, and what should they be doing? I'm using Multiplayer, but for the thought process of somebody thinking about the problem, what should they be thinking about?

Tom Johnson: That's a great question, and I think if you start early with an understanding that your system will get more complex and sort of plan for that, whether it's in the design of your software or the documentation, you'll thank yourself later on.

Julian Wood: Does that not just slow you down? Because you're a startup wanting to go gung-ho and build something. And if somebody says, "Oh, we're not releasing that because the documentation is not up to date," will the rest of your teammates laugh at you?

Tom Johnson: Sure. 

Julian Wood: I'm being sarcastic.

Tom Johnson: But you've hit upon something, like, people end up skipping it because it's manual work and it's not valued in the beginning. Then I find that when you reach about 10-plus people, maybe 10-plus components, your system and your organization is too complex to manage easily. So your system, it's hard to keep in your head all the dependencies. It's hard to then communicate it to others if you're growing and you're onboarding somebody. Well, you have to teach them about what you're...you have to answer, what is your software? It's a hard question to answer the more complex the system becomes. So tooling should do this. You should have this stuff, more of the stuff, automated and automatically done for you. It's part of what we're looking to do. Because everybody makes the same mistakes in the beginning. They skip these steps of documenting, and then you just have to pay for it later, so.

Recommended talk: Deno 2 • Ryan Dahl • GOTO 2024

Julian Wood: There's an interesting thing that I've actually been picking up here at the conference today about not just the auto-generating of documentation after the fact but how some application architectures, in a way, start with the documentation. A bit of a long-winded intro where people generate a database schema, for example, in a way, you are documenting what your database wants to look like and that then drives the architecture, the read-and-write patterns for your database, for example. But at the conference today, I was at a talk about Deno, which is a very lightweight JavaScript runtime, and part of what Deno is coming out is they're saying that NPM as a package manager hasn't had much innovation. And so they've come out with a new package manager called...oh, of course, the name is escaping me, but it's something like JSX or something. I'm sure, on the screen, we'll sort out what the proper name is.

But part of that was in your TypeScript files, you would just export your functions and all those kind of things. And then when you upload your package to the package manager, it auto-generates the documentation based on what that is. Makes me also think of OpenAPI specs or AsyncAPI specs, where the documentation and your architecture are linked together, and it seems to be a way that sort of is an obvious thing to have these two things separately rather than having to retrofit everything.

Tom Johnson: Right. So anything you can do like that to sort of automate the generation of this very important information, the better. We're built on open telemetry. So if you're building a system, you probably want to observe it. You want to treat it as a black box. What we do is we tie into the observability data, and it's the same stuff you're sending out to your APM tools, but we're looking at it for documentation. That's kind of the same thing where you're working on something important to your system, whether it's the NPM packaging or specs that generates documentation. But here, it's like, you just want to be able to observe your system, and why not use that same data to help you in another way?

Julian Wood: That's interesting to think of observability-driven documentation, for want of a term, because your observability in your open telemetry is exactly what your application is doing live today, and you are sending out your observability tool for your metrics and your logging and your dashboards and all these kind of things. But creating documentation like that seems like, thinking now, you're like.

Tom Johnson: All the data is there, and you're already collecting it.

Julian Wood: And it's correlated across multiple services...

Tom Johnson: Exactly.

Julian Wood: ...and how this connects to that. We always talk about asynchronous processing and how a producer and a consumer never need to know about each other. But you want to know who's talking to who.

Tom Johnson: Exactly. And the only way to do that accurately is to have your system tell you what it's doing and then discover it and track it. Otherwise, there are other methods. Other projects try to sort of reverse engineer from the bottom up, maybe your logical platform from the infrastructure as code or from the source code itself. But there are so many problems doing it that way. It ultimately comes down to your system as your source of truth. And if you can get it to tell you what it's doing, then that's fantastic.

Julian Wood: In fact, even thinking about the sort of definition of observability as compared to monitoring is inferring what's going on in your application from its outputs, and this is exactly documenting what's going on in your application from its outputs.

Tom Johnson: Exactly, exactly. And then you add some ability to debug and do some other things that are sort of pain points. Anyway, that's what we're trying to do. But I find that what's an interesting trend these days is just how complex it is just to get a "Hello, World" application up and running. You need to know Terraform, maybe Kubernetes, or other things, or else you have to hack some things together, sort of throw it up, and deal with the consequences later on. But I think that there needs to be a solution for the organization of software things that come together when you're working on distributed systems, and I think that's left to be solved. That's a big unsolved problem. I think that AI will come into play a little bit, but it's not going to be...I think you need data about your distributed system in one place in order to be able to apply AI for things like asking questions about your distributed system, understanding it, changing it, and all of that. So there's still a lot we need to do, I think, to be able to effectively work on these complex systems.

Julian Wood:  In terms of the sort of insights that come out of it, is it a graphical representation or text representation? Because you're obviously talking about AI. You know, GenAI is great at creating documentation. What does someone see? Is it just a page of documentation about this kind of thing, or what does it look like? So people can sort of visually picture.

Tom Johnson: I think that people best absorb and communicate this type of information visually. If you think about coming on board at a new company, a new team, the first question you might ask is, what is your software? And typically, that's somebody going to the whiteboard and drawing some boxes and dependencies like, "This talks to this, talks to this. Here's all the software components we have, here's what we use, and here's how they talk to each other." That's usually the first step.

So I think there's a big visual element to this because it's easy. A picture is worth 1,000 words. It's easy to look at a picture rather than read a lot of text. And with these types of systems, they luckily can be described with visual metaphors pretty easily. I mean, I love things like sequence diagrams and other stuff. Hard to do manually. I mean, that's all the stuff that manually is a real pain.

Julian Wood: And they're out of date as soon as you finish taking it.

Tom Johnson: Exactly. So putting that aside, if you can get a visual representation of your distributed system, maybe flows, things like that.

Julian Wood: That's also an interesting point. There may be different ways to represent the same data, and there may be moment diagrams or flows or this kind of thing in even the same data set. You wouldn't manually create multiple views of the same data because it would seem to be duplicating work. But for different parts of your company or different people within your company, they may want that visualization, because it's looking at a different aspect of your software architecture.

Tom Johnson: I talk about sometimes how diagramming is not designed. It's a system design. Diagramming tools are really all you have available, not really built for system architecture and other stuff. But they don't let you do the things you just talked about. Have one source of truth about your big architecture. But let me zoom into this, or let me have a 10,000-foot view and then zoom into subsystems, or have special views of my ops-related services and see how things...or my data services, or how authentication works, all these questions. You have a lot of questions as a developer, especially when your system gets complex. And you need tooling to help you slice and dice and visualize things as you want. Because design is...I also like to say, design is a team sport, too. It's no longer...I mean, in the old days, you had the one enterprise architect or whatever role, the person who would say...

Julian Wood: This is what you will implement.

Tom Johnson: Exactly. This is the design. It comes from up high down to who will implement this. But these days, everybody's involved. You've got front end, back end, QA, DevOps, your CTO or tech lead, and even, I find, managers who would be maybe using the app that you're developing will have a vested interest in really getting into the development phase, the design phase. Even if they're just involved in what would ultimately be the sort of data schemas for the application, I find that everybody's more technical these days, less afraid to sort of jump in and comment on, ultimately, system design.

Julian Wood: And in fact, you want that.

Tom Johnson: Absolutely.

Julian Wood: You want the challenge from other people's ideas to iterate and have the sort of challenge response of "Let's try this or try that and try and bubble up to the best idea."

Tom Johnson: Absolutely. Because then you get this feedback loop that's quick. So you're not just sort of developing a system and then doing a big reveal in three months just to find out that it wasn't quite right, which happens frequently if it's quick cycles of, "This is rough sketches and mock data, and nothing works. But here's a screen that shows a little bit about what we're trying to do." And if that's on a short feedback loop, then you're more guaranteed to design and develop the right stuff.

Julian Wood: It's just making me think about the sort of live element of it, obviously, with an open source angle being open telemetry, because I think it's going to get to a future where everyone's going to just send open telemetry. That's just going to become the industry standard.

Tom Johnson: Right, I agree with you. 

Julian Wood: So whether your partners or within your company, with external companies, anyone, cloud providers, that kind of thing, you've got a common format that's going to be able to send that data.

Tom Johnson: I agree with you. And when you have that, then you can break the silos that currently are there right now. So one of the things we're trying to do with our debugger is if you have a partner, you're both on Multiplayer, you can have the same debug session. They can see their data. You can see your data. So it breaks that silo of their data just over there. Your data is over there. We rely on each other. We're in dependencies of each other, but we can't really look too deep into or debug things easily. It's really tough.

Smarter Debugging and Platform Engineering

Julian Wood: So you mentioned the debugger. That sounds like the world's hardest problem is to debug things across all these different services. How does the debugger work then?

Tom Johnson: So we do some special things with trace IDs to insert a short session ID, which can travel across the traces.

Julian Wood: Sort of correlation ID or something. Okay.

Tom Johnson: Exactly. And that allows us to understand. So with an interaction that's multiple traces, we can pull it together in one place. And we have a front-end component that captures screens and all that. So we've got from the front deep into the back-end. But then, across boundaries, if you're integrating with somebody else's API, a partner API, and they're using the debugger as well, well, instead of just saying, "Hey, there's this issue, your problem, go figure it out. It happened around 3.30 yesterday. I've got this cryptic message. Go look in your APM tools," you could just send them a link, and then they get a filter of their open telemetry data for the same session. So again, it's taking that manual work. There's so much that's manual in what we do as software developers. You'd think that we automate all sorts of other industries, and I'm surprised we haven't solved this problem for ourselves.

Julian Wood. It seems like an obvious thing.

Tom Johnson: A long time ago.

Julian Wood: It's also, I would say, over the past 10, even 20 years, there's been a huge amount in terms of software architecture and diagramming tools. I'm thinking of, like, Simon Brown's C4 model, spoken at many GOTO conferences, really good. Even Simon Wardley's Wardley mapping is about diagramming and user flows and needs and the evolution of things that are happening. Even domain-driven design or doing event storming is ultimately a visual Post-it note on a board to visually put apart your application. This is interesting to see how those different approaches in the design aspect can be shown in real life in a real tool based on your real data.

Tom Johnson: I think that some of those specs are very important. We export to different formats. But it's the manual part that's the problem. And that is ultimately the thing that I think everybody struggles with. It's funny, I talk to a lot of companies, and everybody's got horror stories about how they update their stuff, how infrequently it happens, when they develop, they're kind of in the dark, the problems of not knowing what the real dependencies are and what the source of truth is. There's a general fear, I think, when your system becomes complex enough that, like, "If I change this, am I going to break something?" Because feature development is...you're never changing all of your services, you're probably adding a service or changing some APIs, adding a few things. But they're touchpoints. And so anything that has the word manual in front of it, it's going to be out of date quickly.

Julian Wood: It's always done with good intentions, even talking about domain-driven design, for example. You're setting up all your context and your boundaries and all these kinds of things, and that looks all great on paper. Then you hope the implementation of that is actually correct. You don't know whether your domain boundaries are leaked and someone is sending an event from there and it's landing up for microservices across and being consumed. You're like, "How did that happen? This is all meant to be an in-domain event." So having something to even catch that or visualize that, because those are the kind of things that trip you up, when you then do make a change, you think your microservice is isolated, and it isn't.

Tom Johnson: Then you've got technical debt. And you have to choose. Okay, you're probably not going to fix it right away. Then you have to live with it for a while and things pile up. And I think that there's going to be a trend toward doing more design upfront rather than jumping into implementation. And I think that's really important, especially as systems get complex, to socialize an idea, to say, "I'm going to add this service, maybe a couple of dependencies, and socialize." Some companies are formal about their processes. You've got to get approval. But many aren't. It's very loose. But it should happen. We have PRs for when you're done developing, "Okay, let's review it when I'm done." Well, that's kind of too late. It's a good gate, but there should be sort of a design review upfront where you say, "Okay, I'm going to make these changes to my system. This is what I plan on doing, changing these APIs, adding these things. Share it with everybody."

DevOps needs to know what they're going to manage, the new stuff, and QA, what to test, and the front-end, what they're going to consume, the back-end, how you're going to change your system. And then you can have those discussions, those philosophical discussions, if you love or hate microservices. I came across a new term that somebody shared with me last, macroservices. So instead of monolith, sort of, like, breaking things apart, but the least cuts, which I think is a cool term. But whatever your philosophy is, it's like you've got to...if you're not sharing what your plan is to implement features, you're probably going to drift from your philosophy.

Recommended talk: Building Event-driven Apps at Scale • Tom Fairbairn • GOTO 2022

Julian Wood: Specifically with monolith macroservice, a lot of people have completely overdone it on microservices and have these little tiny things, which is a management overhead. But the more distributed you get, it's impossible for one developer, or even a team of developers, to reasonably understand everything that's going on in these services and put it in their head and go. Actually, we started off by having these microservices. Actually, why don't we combine three of those together? It would be much better.

Tom Johnson: Sure. Absolutely.

Julian Wood: But how would you pick that or know what to do?

Tom Johnson: It starts with you've got to have a source of truth about what your software is. I mean, if you have that, then you can make these sorts of decisions. If you can trust it, you can put a plan together and say, "You know what, let's combine these things. Maybe we went overboard," and be able to make smart decisions about evolving your software. But I think that is a change that I'm seeing in the industry where there's more care about your platform. The term platform engineer is relatively new. To have people who are not just thinking about DevOps and sort of running infrastructure but taking a platform perspective.

Julian Wood: A product perspective on the platform.

Tom Johnson: Exactly, exactly. I mean, I think that's pretty exciting. I think that's a new trend that will bear fruit, I think, over the years where the platform is your product. And every company that has software has a distributed system, and everybody should think about their distributed system as a platform.

Julian Wood: A lot of people are not thinking of it like a product, and they create these inflexible platforms. And then they're surprised when people don't use it, or they're surprised when people use it in ways they didn't intend. That's not a product. A product needs to evolve as well. It needs to have a marketing function and evolution and budgeting and all those kinds of things. Another whole tangent to go down.

Tom Johnson: Yes. That's definitely an exciting topic.

Early Mistakes to Avoid When Building Software and Teams

Julian Wood: So circling back to some of the people aspect of this, because we're not yet at a stage where GenAI is going to write all the code for us and generate all the documentation for us and create the perfect service architectures, there's still humans in the loop so far. And so, in your learnings, people start with good intentions, and maybe even a single person starting a startup builds something successfully. What are sort of some of the mistakes they make which they should catch early on or avoid doing early on or do things? And surely, it's going to be the documentation as well, as you've been mentioning, but even some organizational things or anything, what should people be thinking of far earlier than they currently do?

Tom Johnson: Yeah. So if I were to advise an entrepreneur starting out a small development team, I would say keep it simple. Absolutely keep it simple. I mean, I won't get into the religious arguments about microservices and monoliths, but I would...just overall, because systems evolve over time and teams evolve, so there's no wrong decision after a while. It's like what works for you. But when you're starting out, just try to keep it simple. I would say monolith. I would say monorepo. If you can, I would try not to write everything yourself. So when you do that, that might mean bringing in a cloud provider service or a SaaS product.

Julian Wood: That doesn't mean you've got your application and multiple developers working on it. This is using either a managed service or an existing library or something else. Okay.

Tom Johnson: Like S3 for object store. You're not going to try to write that yourself.

Julian Wood: Okay. Yeah. So don't go too low. Use something. There's a great talk called "Standing on the Shoulders of Giants," and it's all about Luc van Donkersgoed who works for PostNL. And it's this great analogy of using other people's great work and then standing on their shoulders to create something even greater. 

Recommended talk: Programming's Greatest Mistakes • Mark Rendle • GOTO 2023

Tom Johnson: Right. So, exactly, that's a great way to think about it, where you're composing your platform from as much that's out there that's sort of bulletproof, tested, try to keep it simple as much as you can, but know that your platform will evolve, will become more complex, there will be more people coming in. Plan for it to break up a little bit. So even in a monolith, even if you have a modular design with some clear points to cut, if you need to scale something out, not everything sort of scales together, sometimes you need to run things on their own. We have real-time collaboration. So our collaboration service needs to scale on its own separately from some of the other components in our platform. So try to keep it as much together as possible.

Julian Wood: So there is if I'm thinking about it, I think what I'm understanding you saying, you have a monolithic code base, but within that code base, use good coding practices to separate your code out into...

Tom Johnson: Modules.

Julian Wood: ...be it separate modules or those kinds of things. So although you're not prematurely optimizing, which is certainly something to talk about, good software practice means that module could go somewhere else.

Tom Johnson: Yes, exactly. If you needed to break it out and put a RESTful API on it or something, it's not a complete rewriting. I mean, it's more of a little refactoring. So thinking about APIs, even if the API is just a class interface, is, I think, important to do in the early phases.

Julian Wood: Is that one of the harder things? Because sort of AWS, and Werner Vogel had a quote, "APIs are forever," and that's the kind of thing that really locks you in. People get worried about lock-in with things, but the APIs lock you in because that's how your customers interact with you.

Tom Johnson: YWell, when it's internal services, you have a little bit more freedom for refactoring.

Julian Wood: If you've well-documented your APIs.

Tom Johnson: Exactly. But if it's external, oh, boy, that is...those are...

Julian Wood: Painful.

Tom Johnson: Yes, you can change things, but you just don't want to. Because when you have your customers or your partners write code that integrates with your APIs, they want to write it once and have it run forever. Maybe if you add a new feature, they'll add. But if you say, "You know what, you need to change this API method to change the parameters or change this to that," they will not be happy. So depending on your business, you might not be able to do that kind of stuff.

Recommended talk: Effective Platform Engineering • Chankramath, Cheneweth, Oliver, Alvarez & Reisz • GOTO 2024

Effective API Design and Communication for Development Teams

Julian Wood: Is there any advice on that kind of API design of trappings to avoid?

Tom Johnson: Boy, keep it simple. Keep it modular. It's hard to be general.

Julian Wood: So keeping it simple, yeah...but, I mean, keeping it simple is just having less API routes or having a naming thing that is flexible or can...

Tom Johnson: Some common things, some built-in versioning. I prefer to have the version in the path. There are lots of different approaches. Do whatever works. But have some versioning. That helps. So if you need to change things, you can have the old API active when the new one is there and have a transition, which is necessary. That alone is important.

And then I think about the different kind of, for lack of a better word, objects or things, have a thing-based approach to your API paths so people can read it and it will make sense. You've got a thing and then actions on that thing. That's helpful. I've seen a lot of crazy APIs that make no sense. But the ones that do generally follow that kind of approach. And simple, small, only add the things you really need, no more. I also see lots of extra endpoints and other things that are maybe rarely used or add complexity. So just keep things simple.

Julian Wood: Obviously, it's a trade-off to build all the things because then people are going to come and use all the things. But I know in the architectures I've been involved in that you're often quite surprised how your customers are going to use your application or going to use your service, and you really need to figure out, based on usage patterns, which also links back to the documentation, being able to visualize how your application is actually being used on what the evolution is because there may be parts of the application that resonate way more with customers than other parts. And if you've prematurely optimized for the wrong path, that's just going to be painful.

Tom Johnson: Well, it comes back to system design as a team approach, where the team includes your partner, includes your customer. There's a lot of communication that needs to happen when you're designing systems, developing systems. And the more you can communicate with your team, your partners, and have a quick iteration cycle, the better off you'll be for evolving, developing your system. As you said, you want to know what's resonating with your customer. Part of that is watching what they're using. Because they might tell you one thing but sort of do another. I found that from time to time. So I also like to recommend to people to design and develop as transparently as they can, especially if you have customers and partners relying on your APIs, because you want that feedback early, very early. The features you're developing, and everything around that, the APIs, or whatever, they help you with choosing how to scale your application, what to break out into a service versus adding to your monolith.

So it's funny that we talk so much as developers about the coding of these systems and the complexity there, but I found that the sort of social parts, the communication, is the sort of biggest thing or indicator of success. If you do it well, do it transparently with your team, with your customers and partners. You're much better off and less likely to develop the wrong thing, less likely to have technical debt that piles up, and probably end up being a more successful business at the end of the day.

Julian Wood: I mean, that sounds simple, and maybe we would try to say, "Oh, just communicate better." But practically, how do you do that? Obviously, within a team, within an office, and we've had a pandemic and remote working, and some return to offices, kind of mandates going on, how does one communicate within your own team and then strategies to communicate? You mentioned even customers. How should people think about communicating better?

Tom Johnson: That's a great question. And part of our tool is to help people communicate. Have your source of truth and have an environment where the whole team and your partners can come and collaborate on the same documents, the same source of truth, communicate about design that's coming up, what the system is now.

Julian Wood: So some of that communication is actually just the visibility of what you've got.

Tom Johnson: It's sharing what you have. So having that source of truth of what is your software, having a good answer for that that's up to date, and then sharing it with people and having them work on it in that same place so that they know that they can go to that place to get all the information they need about where your system is now, where it's been, which is also great, to see past versions of your system. It's cool to watch a system evolve and say, "Oh, we started here, and then we had these services, and then this happened, and the scheme changed."

Julian Wood: That's interesting, because there is a story in history, and it's very easy to look at the current state and go, "That was it," without understanding what had been formed.

Tom Johnson: How did we get here?

Julian Wood: How do we get there? Because there were decisions that were made in good intentions, and there were the right decisions at the time, but those decisions need to evolve. And having some sort of decision record over time that you can easily look at will help you understand your software.

Tom Johnson: The information is there. With a good tool, you can save it for posterity. But it's not going to be looking at the Git logs. It's not going to be looking at the Jira tickets. I mean, nobody wants to...I don't know who looks at that. Everyone wants to get out of Jira as quickly as possible. Love it, but hate it too sometimes. And it's not code. It's not looking at tickets. It's too low level. So having a higher level of thinking that everybody can collaborate on is pretty important.

Julian Wood: So I mean, I'm thinking also again back to pandemic and teams working remotely and separately. Is this sort of the new equivalent of the sort of team whiteboard, but it's a sort of live dynamic view of the application?

Tom Johnson: It's kind of purpose-built. So diagramming is not design. And you need a space for teams to get together and collaborate on the things that are important for design. And then, when you do that, you can have the confidence that what you're developing is...I mean, ideally you want everybody in your team to know what you're building before you start, while you're doing it. So when you get to the pull request, it's like you're bright on the money. This is exactly what we talked about. And I'm not surprised by what you're doing.

Julian Wood: It's not, "Oh, what is this? Let me see."

Tom Johnson: What are you doing? Why did you do it this way? Which is very common. Which is a very common sort of thing to face. And then you're always moving on to the next thing. So to have design incorporated into better incorporating the development process will let you develop faster, because then you can move on to the next thing. Design is done. Development done. Matches the design.

Julian Wood: Implementation is the design.

Tom Johnson: Exactly. And then now we can move on to the next thing. And we don't have to worry about what we just did. We can, with confidence, know our system is evolving. Because that's one of the biggest things. These systems are dynamic. They are quickly changing. Teams are dynamic, too. So you've got the organization and your software kind of, you know...there are a lot of things in common. Dynamic, complex, and…

Recommended talk: Unbundling the Enterprise • Stephen Fishman, Matt McLarty & Erik Wilde • GOTO 2025

Effective Software Teams and the Future of Development

Julian Wood: And many people build software based on their organizational boundaries, which is normal, the common law. So yeah, what would you even say to teams in terms of setting up teams and setting up the people aspect of writing effective software to have better collaboration?

Tom Johnson: That's a great question. So we're a remote company, distributed. We have people in Portugal, Armenia, Kyrgyzstan, Romania. And I don't know. If you're hiring people, I would recommend you take the best people wherever they are. And there are great tools to have that feeling of camaraderie. And even though it's virtual, with Slack and Zoom or whatever you use for video conferencing, I would say that, as long as you're set up to communicate, well, I guess it comes back to communication, then you can develop software effectively, regardless of where you're located.

Julian Wood: So in a way, it's sort of actually leaning into the communications part first, which simplifies the organizational communication boundaries. Because with rigid organizational structures that don't communicate effectively, that seems brittle.

Tom Johnson: Right, right. So if you've got the communication piece down, short feedback loops, talking to people on your team frequently, have transparency about what...I guess, if you're a manager, clear goals, clarity from the top down of what should be developed, the features that are in the queue that should go out, and then transparency about design, development, then you're set up to move quickly. And I think the best teams do it that way.

Julian Wood: Casting you a bit further into the future, when either of this is all solved, and whether using Multiplayer or whatever you're doing, in sort of a few years' time or something, if you were looking back, what would people have achieved, and how would the software business have evolved and changed to sort of create or bring to life what you want in it?

Tom Johnson: We're trying to, like, invent the tools that will be used in the future. So hopefully, one of the things we have in development is what we call the platform designer, which is a composable interface to take pre-built services and SaaS products and then compose a platform and click to deploy on different environment types. I think the future is infrastructure is going to get abstracted away, and we're going to be developing software to software, and you're not going to have to worry about Terraform and Kubernetes config and all this other stuff that.

Julian Wood: I mean, I work for AWS in the serverless product org, and that's, like, part of the way of that journey there of abstracting infrastructure. There's a whole lot of work still to do. Yeah.

Tom Johnson: Right. And it's just because all these tools are great, but you have to know so much just to get a "Hello, World" platform up and running. You can hack something together, sure, really quickly, but if you want to start right, you have to be an expert in too many things now. So I think that in the near-ish future, it will be infrastructure abstracted away. You're not going to be thinking about virtual machines. You'll think about CPU allocation for services and memory and things like that.

Julian Wood: As a resource rather than...

Tom Johnson: As a resource, exactly. Not where it's going to be. Maybe you'll say, keep it close, or it can be far away, or it can be an object source or whatever, but you'll be thinking more about software talking to software. It will be about APIs. It will be about services and whether that service is something that somebody else wrote that's open source that you'll just sort of drag into your platform and run as a container, or a SaaS product, or a cloud service that's on a cloud provider. It will be cloud agnostic. It will be, you know, this kind of infrastructure stuff. You won't have to think about it. And I think it will be a better world because people will be able to move quicker. They won't have to be experts to get their startup idea off the ground.

Julian Wood: And easy to get into, I think. Ee talk about the amount of software engineers in the world. I mean, it is a tiny proportion of people. And the barrier to entry is crazy high to become a software developer, the amount of time in coding. And I know GenAI is awesome for helping you explain code and help with that. And I mean, I'm not meaning that in a sarcastic way at all. Like, learning to code now, I think, is much easier with GenAI. But if we can lower the barrier and the infrastructure stuff and people can just understand how software works, yeah, if we could double the amount of software engineers in the world, I mean, that would be a great thing.

Tom Johnson: Yeah, that would be great. And I think that...I love GenAI for a number of things, but if you can get it to, for example, generate some Terraform for you, but you still have to be a Terraform expert. You have to know...

Julian Wood: If something goes wrong, yeah.

Tom Johnson: Exactly. So there's tooling that has nothing to do with AI that can be created, that can help create this future world where, you know, you can just get an idea off the ground really quickly.

Julian Wood: And I think there are going to be many tools as well.

Tom Johnson: Yes, absolutely.

Julian Wood: I think that's probably another whole conversation about how the art of creating tools is going to become much better, that you're going to be able to have much more targeted, specialized, simpler tools to create for different use cases. Yeah, that's going to be an exciting thing to create this future with smaller, little composable tools.

Tom Johnson:  I think the next 5, 10 years is going to be really exciting for distributed systems. And thinking about the evolution from desktop software to client server to microservices to all these SaaS products and cloud products and these great projects like Terraform and Kubernetes for orchestration, solving some tough problems, suddenly they're going to be in the background. It's more of, like, the plumbing, and you just compose and just think about software. It's going to be a pretty... I've always wanted that world. I can't wait for it.

Julian Wood: Getting there, getting there. Tantalizing. Is there anything we haven't covered today that's top of mind or to think about?

Tom Johnson: No, I think we've covered quite a bit. Thanks for having me. It's been a wonderful conversation.

Julian Wood: Well, thanks for joining us. And yeah, thanks for joining us on GOTO Unscripted here in lovely Chicago. Being able to speak to many people at the conference is a pleasure. I get to learn as well. Thanks for spending your time with us here today. Thank you.

Tom Johnson: Thanks.