Well, it's the time of year that the forecasts come out from all the big shops. I haven't gone to see what IDC's enterprise—well, let me back up. I think it's all IT spending that they come out with because it's in the trillions, which means it includes consumer spending. I don't know if it includes gaming, but it probably includes Apple. As always, if you took Apple out, maybe you would have the IT spending for the year. I was listening to a podcast going over, like, of course, like, you know, chip supply chain stuff, and Apple comes up, and I'm always reminded, like, that, wow, that is amazing. They make so much money, and they're such an integral part of society. Anyhow, Gartner and Forrester, I haven't checked IDC, and I don't know. What are the other ones, Ed, Canalysis or something? There's about five or six, like— Asparagingly, maybe, some of them. Yeah, yes, forecasts. But it looks like—let me start, as always, with our concerns, fellas. And it looks like in the software and cloud and cloud services business, we're looking at about, like, it is a decrease from earlier forecasts, but we've got about a five—not about, way too precise—a 5.1% growth rate in spending ahead for us in this year. I think it's CY 2023. We're not looking at an FY, which is fine. So you might need to load up the spreadsheets and adjust it if you're on some sort of, like, present company. No, I can do calendar years. Financial years are so much harder to keep in my head. Indeed. Because they're normally the wrong one. And so it looks like—so their estimate is there's going to be $4.5 trillion of— I think this is, as I like to joke, I think this is terrestrial spend. I don't know if the secret world of low-Earth orbit and Moon and Mars colonies, if this is included in it. So we've got $4.5 trillion of terrestrial spend, which is a 2.4 increase from last year. Again, I think it's calendar year. And it looks like this quarter is—anyways, I get all this stuff mixed up because who cares. But, like, in the segment that we're in, we've got 5, 5.5% growth.
2:02So as people like to joke from the lovely show Arrested Development, there's always money in the banana stand. Whatever may be going on in the economy, software tends to be a good, bright spot. Because, after all, if times are good or bad, you need computers. It's always a requirement. Things will be a lot worse if you don't have computers, is my general finding. Except when it comes to, you know, your own self-mental health. However, that's a topic maybe we should discuss at some other point, is, like, I always imagine myself, you know, trying to encourage my kids to spend less time on the screen. But it's really interrupting the time I'm spending with my phone to manage that. I was going to say, that trillion in gaming, I feel like I contributed heavily to that, trying to buy Fortnite V-Bucks this Christmas for my kids. Ah, yes. Yes, we're obviously in the same space there. So, what are you, you know, you're always scanning the news out there, listening to the wires, like that guy in heat, you know, up in the camper, as you would say, on the mountaintop. What are you seeing as far as the forecast and the spending, you know, at the moment, in the past, like, 60-day moving window of buzz? 60 days. Was it within that? I'm not. Probably. I mean, much the same, right? You've either got the doom-mongers saying everything's going down, even the cloud providers, you know, are seeing a slowdown, hence all these layoffs, all that kind of stuff. There's some analysis. Who was it, Bernard Golden? I think we talked about before, I mentioned before, maybe name-dropped, whichever, pointing out the underlying growth for them was still going up. And I think we all still feel that, that it's still, like I said, software's still a good place to be. It might not be as good as it was a year, a year or two ago, but it's still a good place to be. I think you only have to look at, you know, again, the chat GPT kind of stuff, right? It's very easy software to just suddenly everyone go, wow, that's a cool new thing. And that has dollars attached to it. I've already seen all the YouTube videos spanning off that of people then saying, great, we'll hook it into here, here, and here. So whether it's cloud, AI, all these, you know, data, they're still going to make changes.
4:04They're still bringing value and doing new things. So I still think there's a sense of optimism. The finances might go down, right? But long-term, people still feel like that's going to come good. We should still be in it somehow. And I guess when it comes to forecasts, that is, it's perhaps the most, is it inhuman or unhuman? I forget how Rob Zombie put it in that song way back when. But anyway, it's like the most inhuman sort of forecast because it doesn't really indicate how many people where they'll be hired or laid off to help enjoy this spend. But it does look like the other thing in this coverage that I think is interesting and ongoing is this dissonance is too fancy of a word, but I will use it nonetheless, is the notion that like all these tech people, I think the current roundup from, as John Gruber kind of posted from a CNBC article, is that there's about 60,000 people in the, it's probably mostly U.S. centric, but in the kind of tech world that have been announced that are going to be laid off. Boy, that was a sentence that my sixth grade English teacher would have just puked all over right there. But meanwhile, as covered in both the Forrester and the Gartner forecast, or maybe only the Gartner one, like there's still a regular or normie enterprises are still desperate to hire people. So it is this odd, like this odd sort of disconnect between the two of them. But I don't know, it seems like, you know, from your perspective, Ben, when you see these forecast numbers, what do you do? Are you like, oh, got to go get another cup of coffee or do you get excited about them? No, I think Ed's right in terms of the industry itself. It's surprisingly resilient to, you know, these sort of downturns. And I'll take 5%. That's quite a good number. I'll take it. Yeah. That sounds great. And, you know, you were talking about other parallels. So I did see one about gaming. There was a survey about gaming in the UK.
6:05It's quite important to the UK economy. It generated 11 billion GB pounds last year. So it's a big industry. And there's been quite an explosion in things like university courses that deal with various aspects of game creation. You know, everything from project management all the way through to, you know, art design and graphics and storytelling and everything really. So, you know, yeah, kids' screen time. What do you do about that? It's like it could be the best time they're spending in the day. Yeah, yeah. Career-wise. It could be. But at the same time, it might not be. And I think, I mean, just a rat hole on that a little bit. Like, it is, I remember when I was a kid, I spent a lot of time trying to, like, send a message in a bottle in my memory palace of, like, hey, remember when you thought those adults were a bunch of, you know, these video games are melting your brain and TV? Like, just remember what you thought about that in the future. And so I try to apply that kind of thinking from my childhood. There's a lot of other messages in a bottle I sent that you just open up as an adult and you're like, yep, that's what a six-year-old would think. But anyways, like, I do, I struggle with, I guess it's more, as always, about the time you spend on good activities versus bad ones, right? Because I, I played a lot of King's Quest and even though I shouldn't have been at the time, Leisure Suit Larry and Sop with Camel, things like that. Risky. Yeah. But, but then also, like, I spent a lot of time typing and, you know, writing things and stuff like that. And I often, like, I haven't, as always, when it comes to kids, I can never, my kids, I can never figure out how to have them both understand and then enjoy the dad wisdom I give them. And what I try to tell them is, like, if you just spent, like, four hours a week on wholesome activities, I would almost not care how you spend your other time.
8:09But you got to, like, there's this floor of helpful stuff you got to do. And before it's, I don't know, and this is, this isn't a parenting advice podcast, although. Well, everything, balance in all things. That's what you're saying, isn't it? Balance in all things. And, you know, I like the reference to the memory palace there. Sadly, I'm in, I'm in charge of the DIY of my memory palace. So it fell to pieces here years and years ago. You're just the, you're just, you're just, did you, did you all, did you all have that show we had in the States that was, what was the name of it? It was one of those big family shows. And there was this, there was this, the super, the repair person, Schneider, with the leather vest. And he would run around with his, his big old, like, Magnum PI 70s mustache and his belt of tools. And he's always fixing stuff up. You got to have a Schneider in there doing things. Well, speaking of DIY, you know, I thought, I thought a topic that might be interesting to go over is just kind of, I mean, this is a reoccurring topic. But kind of, you know, you can't use the word trolling anymore, as in dredging stuff up, right? Like, you know, where you would, like, throw a troll out there to just kind of, like, collect up. So I need to find a new word for that, because trolling has been taken over to mean something entirely different. Anyways, as a kind of collecting up of what we're seeing in the area of low code, I'm always really interested in what's going on there. So, you know, first of all, I just by coincidence of planning this, I was at a, like one of the, like an executive dinner, two nights ago now in Brussels. And I just happened to one of the persons, the persons, one of the people I was sitting next to, I was asking, he brought up low code, and I was asking about it. And they, this person was, had been using low code a lot in, I forget what type of organization it was, but, you know, big, big enterprise organization. And there's a couple of things that, that, that he said about low code usage after doing it for a couple of years.
10:11One, he said that the promise of it, that the kind of, the initial promise of it works, like that you can actually use low code platforms to quickly put together applications. And then there were two other things, but then there were two drawbacks that he was concerned about, or potentials for better management of, to put it one way. And the first one was that it can be a very dangerous tech debt legacy trap situation, because you can have people like spin up or do these kind of low code apps. And part of the speed and also kind of profile of doing it, like kind of the community sort of, it doesn't encourage, but it inadvertently encourages not caring about the, the multi-year sustainability of the architecture and the application that you're doing. You know, not that high code people are that much better at it either, but at least have it there as a, maybe we should do that. That's right. It's, it's at least in their top 10 principles you should live your professional life by like so many top 10 principles through time. They are often not followed except for the really critical ones. And then the third thing that he said that was, that was interesting because this is a topic of, you know, being in software vendors, we always have an odd relationship with. He was like, there also is a pretty high degree of lock-in that you have to worry about. Like there's not really portability from one low code platform to another, let alone any portability. So it is something you have to worry about. And like the kind of like analysis that, that, that we ended up on was that like, yeah, it's probably great. If you go in assuming you're just going to get rid of this application after a year, right? Otherwise it requires a lot of thinking for, for like multi-year stuff. So that's my, uh, my readout. Maybe that's a better word than trolling. That's, that's my sort of like gathering of, of the low code thing at the moment.
12:11But how about yourself, Ed? What, uh, when, when you bump up against low code stuff, what, uh, what are you seeing out there? Um, I just see a massive to-do list for me, as in, I find it kind of fascinating. It's not an area I've ever looked at much. And I, I can't remember when it was maybe a year ago, but I remember also that whenever the last big Microsoft probably ignite was, there was a whole section on low code, no code and their whole sort of power platform. And it's something that, uh, where I am Jersey, this tiny little island, we've got a little sort of digital sector that's trying to do more of this kind of stuff. And they ran a course on no code or low code, no code, which I couldn't do. It was during the week. And I just thought, you know what, I'd love to learn all about it, but I've, I've got other stuff to do at the minute. And that's where it's perpetually sat. But I watched a bit of the, the Microsoft one, which had some sort of very intriguing, you know, take a photo of this scrawled on paper and it will turn it into a UI and do this stuff for you. Wow. That's cool. I think, wow, that, yeah, that looks brilliant. That's very well done. And then a bit of me think, but it won't be that simple, right? Because if it was, we wouldn't have developers. And now, and again, I heard, sorry to go back to it already, but chat GPT comes up. And again, I think, right, actually it's one of those areas that has snuck up on me and I've heard lots of noise about it. I know we had someone internally at VMware who, who turned around a project in short timeframe as a very much solo effort using Microsoft's power platform, pulling info out of Salesforce, did a lot of stuff. And there was a, you know, an internal talk about it. And it's like, wow, that looks brilliant. That looks like something I could be, I would be looking at and going, how can I, like the news gathering, there must be a more efficient way than me doing what I do. And whether it's one of these no code platforms, low code, whether it's a better way of, you know, scraping it, all that stuff is, it's definitely in the realm of, I should be able to go and say to chat GPT, do all this stuff. And whether it's that or some other, and it just every week presents it to me. And that is coming more and more. And I haven't looked at it. And I, one day it's going to just take over something I did. And I'll be like, oh, so, you know, for me, that whole, whether it's power platform and there's others, I'm sure. But there's an awful lot in it. I'd like to learn.
14:11Well, you know, I agree with you about the gathering stuff. And if you, if you ever figure it out, I mean, I think I have spent 25, maybe even 30 years trying to perfect that process. And it all basically always amounts to just like way back when literal or virtual post-it notes just left on a desk. Like that's, that's pretty much best of breed information gathering. In your memory palace. This desk is in your memory palace. That's right. How about yourself, Ben? What have you been seeing in the, and thinking about in the low code area? Well, you were, you, you kindly sent me a link. There was about, it was from the new stack, an article about Amazon's code catalyst, which they came out with at the sort of end of last year, which is kind of like low code for all sorts of developer problems. You know, where do I get my ID from? How is it set up? How do I start a project with some, you know, new piece of code? How do I get that deployed into environments like staging, production, development, et cetera? And they came up with this code catalyst thing, which is a whole sort of suite of stuff, didn't they? That kind of formalizes all that so that you don't have the problems that are associated with regular developer environments. Things like environmental shift, you know, sprawl where things have moved over time and not everyone on the team is on the same versions of stuff, for example, which cause it, which can cause problems with builds and various other bits and pieces. So I was looking through that article that you sent me and I was, I was sort of reading it and digesting it. And I came away with, yeah, there are some fundamental things that it would be really nice to solve, like this problem with drift, you know, between IDs, for example, or the problem of how do I get started with a project with, you know, decent templates and that kind of thing that's
16:14codified all your standards or a supply chain, you know, and this, anyone who's been following my stuff knows I'm doing quite a bit of stuff on the supply chains at the minute. So all of that is good. I think everyone sort of, there's a consensus around that that sort of stuff is good and having that as low code as possible helps people to be more productive. So that is all good. I think the problem with things like, like Catalyst and like you were saying, Coté, about, you know, other low code platforms is I am left with a sense of yes, but in a year's time, if I want to switch away from this stuff, I'm not going to be able to, I get the feeling I'm going to be very locked in to a vendor's particular view of the world. And I don't see much in there around open source standards or things that will allow me to port what I've done to another place safely and efficiently. And I think that's one of the problems. I think the other one, possibly specifically just with Code Catalyst, was I just didn't see anything in that sort of review, if you like, from the new stack about solving the issue of discoverability. Like it's okay to have one team working really well, but the stuff they produce needs to be seen by a hundred other teams. Right, right, right. So if that's not exposed well, you know, if there's no sort of backstage GUI, for example, where they can go and have a portal all the developers can use, where they can see each other's stuff and see each other's APIs and each other's documentation and each other's microservices, you know, where they're running and all that sort of stuff, then what have you really done? You've created a very smooth way of creating more hidden projects. Is that maybe why there are 17 different ways of doing containers on AWS? Yeah. 17 teams did their thing. I joke, right? They know better than that. But I see your point around that, Trees. And it's not even Kubernetes, is it? It's like EC2. So, you know, there's kind of like a, it felt like there was a lot of standard avoidance.
18:16Like, oh, let's just avoid that open standard, all that open source stuff. Because, you know, it's not ours. It's not invented here syndrome. I don't know. It just left me a bit cold. I was like, yeah, I think we agree on some of the problems that we'd like to solve. But I think we disagree on the solution and how open that should be. Yeah, yeah. I mean, to kind of close that out, and then there's something that you're making me think of. Like, I think I found that, well, one, talking with people and seeing what they're actually doing in any area. But in the slow code area, like we were going over, is always useful. But, like, the thing I'm always very interested in is a lot of examples of the apps you would do with it, right? And I think that, like, it feels like, you know, what we've all kind of said is there's a good category of problems, or if you want to be super fancy jobs to be done or whatever, that you can apply this to if, you know, like anything else, it's a tool that used well accomplishes the thing. The old, you know, you don't want to use a screwdriver to drive in a nail. Even though sometimes you're like, I don't want to go back down the ladder. I got this screwdriver here. Let me just try to use this. That's how I do DIY. And the other thing, which I think, you know, it's a topic we should think about how we can, like, talk about ongoing is this idea of discoverability, right? Because it's a big, I think it's almost like a, I don't know what the phrase is, a submarine topic, like in this whole area of, like, I don't know if people still say DevEx, but, like, you know, developer experience and getting better at software that comes up over and over again. But there's not a lot of discussion about it, right? So if you look at, if you look at the Tanzu application platform and, like, you know, similarly, like, or the same, like, what's going on in Backstage and all sorts of things, like a huge component of improving developer experience is just like, as I like to joke, getting a better intranet where developers can, like, discover stuff, not that what's going on publicly on the internet, but that what's going on inside their own organization.
20:22And as you were talking about with low code, like, discovering what other people are doing and seeing if you can use it, right? Like, and I think that, like, just not diagnosing, but finding that idea and then kind of describing how to solve it, hopefully in CY 2023 will come up a lot. And I think, you know, it's reminding me of, we had this other concept called inner sourcing, which might be one of those things we can revisit. There was a whole inner sourcing little conference last year that I have bookmarked in my mind palace from last year. And maybe there's one person in particular, one of my old IBM friends, maybe we should interview him on that topic because he's put a lot of thought into it. So anyhow, speaking of organizations, there's another thing that, was it, was it Rachel? No, it was, it was Steven over at RedMonk. He had a, this is a little like vendor centric, but I think it can quickly, if you're doing like platform engineering, it can quickly become not tech company centric if you're, if you're building the product of a platform in your organization. But he was, he was making the point that, you know, that we, we of like, who have Conway's law tattooed on our, I always find that the metaphor is not good that you tattoo something on your forehead because then you can't see it. And you also have to write it in reverse, which means other people can't read it. So you should really have it more tattooed on perhaps the outside of your hand. You probably would see that more frequently than your forehead. It'd be good on a podcast. Yes. I'd just see it now. My screen's reversed. Everything would be fine. That's true. It was obviously invented for podcasts. Yeah. Whatever this is. Good, good point. Good point. We're solving a lot of mysteries of life just right, right now. But, you know, he was making the point that if you are building a product that, especially focused with developers, you've got to like, or that is going to be used by developers, you've got to change your organization structure around to kind of match the architecture and the development teams that you need.
22:28And I think, you know, particularly for vendors, this kind of matches up, right, that you want to have developer-centric people doing it. But I wanted to explore that idea of, like, what are, like, the ideal organization structures if you're basically supporting developers? And just to start out with, right, like, this isn't contrary to it, but it doesn't fit neatly into it. I was talking with one of our customers at a big organization, and they were noting that what they found for their platform team is that, so they almost implicitly have divided their platform team up into two parts. The people who manage the runtime of the platform, the actual platform, and then the people who are basically the interface to the developers, right? And they might do a little bit, this is commonly, I don't like this phrase, but I think this team is commonly called, like, DevOps engineering, or even developer relations inside of a company. It's changing, it's becoming platform engineering. Exactly, exactly. And the interesting, I mean, not to go into that stuff too much, but the interesting thing that came out of that is this person was mentioning that they found that you want to have these two teams in the same group. Because a little contrary to this point of structure, the, let's call it, we'll just call it the platform engineering team, the ones that work directly with developers. They do work with directly with developers, but to have the most effect on changing the platform, they have to work even more so with the platform team, the runtime team that's building that platform. And that if you separate out this platform engineering team from the people who actually run the platform, your incentives just get misaligned and you don't, it just doesn't work. And so, like, you know, again, like, that's not necessarily contrary to this idea of needing to change your organization structure for developer experience.
24:33But it does show, it does show that you have to put a lot of thinking into, like, where are you going to separate out product management when you're doing things internally. But how about yourself, Ben, what do you think of this idea of you're going to need to pay a lot of attention to the org structure, if you're developing, like we are vendors, like tools for developers, or internally, if you're doing these platforms for developers? It feels right. It feels extremely common sense, what Stephen was saying there. I read through it, too, and I was thinking back to my consulting days when I was traveling around and visiting lots of people and trying to help them become more sort of cloud native. Every one of those organizations had a function. You know, it was either a bank or a retailer or automotive or whatever. They all had a function that was around their product set, you know, and their organization structures were around their product set, including the sort of developer groups and things. And one thing that was very often forgotten about was, OK, if we want to be good at software, then we have to be good at producing it and getting it consumed by people and out into the open. And the way to do that is through platforms where you've got platform runtime folks who can make sure that that platform is healthy, and you've got platform engineering folks who can make sure stuff can get on there quickly, safely, securely, so that you've got confidence in the code that you're deploying, right? Because if you don't have confidence in your code, you don't have anything. You haven't finished. So you've got confidence every time. So the platform engineers are about engineering in confidence. You know, they're about engineering in safety and security, as well as speed. You know, speed is not everything. There's a whole bunch of other stuff that comes along with it if you want to be fully confident in what you're doing. And I think that's what spoke to me about Stephen's article there, was that it's a case of you have to think about your organizational structure and you have to budget for those two teams to exist.
26:42If you haven't budgeted for them to exist, you're probably not serious about it. And if you're not serious about it, why? Because it's sort of fundamentally important. So he had these two fundamental questions to ask yourself about your organizational structure and about the way that you're incentivizing and investing and using your budget, your IT budget, and where that spend goes. And saying, like, is that spend going in the right places? Do you have these two teams? Are they well funded? Do they have a good remit? Do they know what their goal is? So I thought it was excellent. I really enjoyed reading that article. Yeah, yeah, and you're reminding me or buying me the time to think about, to explore the Memory Palace more. I think to kind of summarize the point he was making, I didn't really explain this well enough, but he was saying that the way you organize to deliver a service is different than the way you organize to deliver a chunk of software, right? And I think he was, this probably came, you know, I used to work at RedMonk and be an analyst, and these kind of posts often come up after a call you've had with someone. And so I would imagine he was talking with a public cloud provider, and they were going over this stuff. And he's like, oh, there's a good blog post, which is, speaking of having the virtual post-it notes everywhere, it's always good to be looking out for that. But, you know, I think internally, and that definitely applies to, like, vendors, so to speak. But I think internally, you were just explaining it, like we were both explaining it, the way it applies is, if you're in an IT organization and you're organized around delivering a service, and, you know, the SLAs and the uptime and something working, you still need that. But you also have to realize that you are going to need a different organization structure, in addition to that, about delivering a product, a chunk of software. And it's just a different way of thinking, a different set of incentives and things like that, which is unfortunately easy to miss or something.
28:45Well, we just have a short one here. Well, some people might consider it long, but it's short for our typical thing. We'll put links to all of these things over, as always, at tanzutalk.com, if you want to go check that out. And usually we broadcast these live. Today we did not, because of some exciting enterprise procurement processes, speaking of organization structure. So, this is just the audio-only edition of it, but, you know, we record sometimes on Tuesdays. I think we'll probably, I don't know, I'm always screwing that up. Who knows? We have no predictability due to me. But anyway, you should go to tanzutalk.com and subscribe to this and check out the additional notes. And with that, we'll see everyone next time. Bye-bye. Bye. Bye.