Design & Develop Distributed Software Better w/ Multiplayer • Tom Johnson & Julian Wood • GOTO 2025

Design & Develop Distributed Software Better w/ Multiplayer • Tom Johnson & Julian Wood • GOTO 2025

Show Video

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. 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. One base, one thing. 

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. 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. 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.

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? 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.  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? Sure.   I'm being sarcastic. 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. 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. 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?  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. All the data is there,  

and you're already collecting it. And it's correlated across multiple services...  Exactly. ...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. 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. 

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.  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.  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. And they're out of date as soon   as you finish taking it. Exactly. So putting that aside,   if you can get a visual representation of your  distributed system, maybe flows, things like that. 

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.  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... This is what you will implement.  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.  And in fact, you want that. Absolutely.  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." 

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. 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. Right, I agree with you.   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.  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. 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?  So we do some special things with  trace IDs to insert a short session ID,   which can travel across the traces. Sort of correlation ID or something. Okay. 

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.  A long time ago. 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. 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. 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. 

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. 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. Sure. Absolutely.  But how would you pick that or know what to do? 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.  A product perspective on the platform. 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. 

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. Yes. That's definitely an exciting topic. 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?  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. 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. Like S3 for object store. You're not   going to try to write that yourself. 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.  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.  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... Modules.  ...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. 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. 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. 

YWell, when it's internal services, you have  a little bit more freedom for refactoring.  If you've well-documented your APIs. Exactly. But if it's external, oh, boy,   that is...those are... Painful.  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. Is there any advice on that kind of  API design of trappings to avoid?  Boy, keep it simple. Keep it  modular. It's hard to be general.  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... 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. 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.  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. 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? 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. 

So some of that communication is actually  just the visibility of what you've got.  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."  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.  How did we get here? 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. 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. 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?  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. It's not, "Oh, what is this? Let me see."  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.  Implementation is the design. 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…

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?  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.  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. 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.  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?  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.  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.  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. As a resource rather than...  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. 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. 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...  If something goes wrong, yeah. 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. And I think there are going to be many   tools as well. Yes, absolutely.  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. Getting there, getting there. Tantalizing.   Is there anything we haven't covered today  that's top of mind or to think about?  No, I think we've covered quite a bit. Thanks for  having me. It's been a wonderful conversation. 

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. 

Thanks.

2025-01-25 05:32

Show Video

Other news

Samsung brings purpose-driven AI to its S25 series smartphones. 2025-02-12 08:32
TECH TALK: RETRO LONGBOARDS 2025-02-09 21:56
The unseen world of 3d printing at 1000fps! 2025-02-08 06:39