The DEVOPS Conference Scandinavia Recap

[Marc] (0:05 - 0:28)

I'm just amazed that we're able to walk into a room anywhere in the world with these types of people and talk about ideas. Welcome to the DevOps Sauna, the podcast where we dive deep into the world where software security and platform engineering converge with the principles of DevOps.

[Darren] (0:29 - 0:32)

Enjoy some steam, and let's forge some new ideas together.

[Marc] (0:42 - 0:48)

We are back in the DevOps Sauna. Hello, Darren, and welcome back.

[Darren] (0:48 - 0:49)

Afternoon, Marc.

[Marc] (0:49 - 1:14)

Correct as usual, Darren. We just got off the road from an astonishing week down in Scandinavia. It's funny when you live in a place where you're going down to Scandinavia, but if you are in Finland, it's true.

And we hosted The DEVOPS Conference in Copenhagen and Stockholm as recently as last week from the date of our recording here. How was the conference for you, Darren?

[Darren] (1:14 - 1:34)

It was great. I mean, what our listeners probably don't know is that we're both also part of the program committee. So we go through this huge process of putting this program together along with others.

And it's just great to see the output of that. Like every time it's just I'm so pleased with the speakers we managed to pull in and then they just they deliver exactly as we expect them to.

[Marc] (1:35 - 2:22)

It is. And so for my co-hosts at the conference, Pinja Kujula and I were in the taxi arriving at the restaurant in Copenhagen on Monday night. And we look there and there's a little cocktail table outside the restaurant on the sidewalk, as we do in Scandinavia a lot.

And there's Simon Wardley having a smoke on his phone. And we're like, oh, my gosh, the life that we get to live here. You know, to see people that, you know, Helen Beal, Charity Majors, people that are making the things that we're using and all around the world and the things that we're talking about.

And these are the people that were kind of the originators, the founders of those. And they all come to one place to talk about how cool it is to do DevOps.

[Darren] (2:22 - 2:37)

Yeah. I mean, maybe we should just get started and dive in talking about the talks as you bring up Helen Beal because I know we had her on the podcast, and you were very pleased with that podcast because she was challenging you, and you seem to like it. So how did you find her talk at the conference?

[Marc] (2:38 - 3:43)

It's amazing to get to the root of things and to get to, you know, kind of single source of truth sometimes on the tools. I started doing value stream mapping out of necessity, and then I started to learn that, OK, this is this is not only a thing, but there's this continuation called value stream management. And in her talk, Helen took us through not only kind of the origins and how value stream mapping and management had kind of come up.

And she had these like amazing things to say, like, you know, DevOps hasn't failed you. It wasn't DevOps that failed. It was your implementation.

And, you know, sometimes value stream management in the market is criticized as being a shiny new thing when it's really not. It goes back a very, very long time. So really, really neat to have her kind of out of the gate.

And yeah, when we had our podcast with Helen, have a listen to that if you haven't. It's really, really amazing. You know, here's the queen and mother of dragons of value stream management asking me how I do it with my customers.

You know, you want to hear me squirm. It's a really good one.

[Darren] (3:43 - 4:14)

But following on from Helen Beal, we kind of pushed into what I think was this common theme throughout the day where everyone was talking about the importance of developer experience. And this kind of we've talked about it before, this flow state. And we went right into Chris Davidson from Atlassian.

He was talking actually on what the same subject that Sven Peters from Atlassian was talking about last time. And it's this developer joy and this ability to basically get out of the way of your developers.

[Marc] (4:14 - 5:18)

You know, there's this old thing that many of us had heard, this old meme that, you know, what if we spend money to train our people and they leave? And then it's like, well, you know, what if we don't spend it and they stay kind of thing? And I'm thinking the same thing about developer experience a lot.

You know, I've got customers that are looking to justify investments in developer experience. And I point out in value stream mapping exercises and lots of other times that, generally speaking, all of the value creation in an organization that has software products is somewhere between checking out code and committing it. So everything else that we do, all of the planning and road mapping and, you know, user experience and, you know, taking feedback and all of this.

And then on the other side, you know, testing in many, many different levels all the way through, you know, compliance and deployment. It's also that moment of developer experience where they're actually writing the code. Everything else is to make that better.

So why would we not invest in making that the best experience possible?

[Darren] (5:19 - 6:11)

And it's, again, all about achieving that state where the developers can do the thing they want to do and not be hamstrung by all the things they don't want to do. And Atlassian seemed to be hammering that point home with the first, Sven Peters, and then Chris Davidson this time, just hammering down that. And he said this one thing that actually spoke to me quite a lot, which was social contracts are more important than perfect on paper systems.

And that was just, that was like, yeah, people spend all this time and there's money developing these platform engineering systems, which are perfect. And then no one uses because it's perfect on paper and it didn't actually listen to what the developers want and what the developers need. And I just, I like the idea of getting out of the way and letting the creative people be creative in the way that they can.

[Marc] (6:11 - 6:56)

One of the things that I urge decision-makers to do is, you know like Atlassian is one of the greatest examples at the moment. It's like, if you're using these tools, why don't you look at how they're built? Why don't you see what kind of internal values are creating the things that you are paying for or taking for granted?

And Atlassian has been having a really high level of internal developer experience, and they have been celebrating that by sharing the best practices all over the world. And it's, it's really fantastic. And Chris Davidson absolutely knocked it out of the park and his, his energy was fantastic.

And I think this is, this is one that going back and listening, watching the recording, I think can help just about anybody that's in the software space.

[Darren] (6:57 - 7:22)

Okay. Yeah, I don't disagree. Next up we had Dan and Emma from VELUX.

We again had on the podcast, they kind of made a set of movie references regarding platform engineering, which I wasn't expecting. I was expecting a lot of things from the conference. And one of them wasn't how to understand platform engineering and the pitfalls in it framed in obscure movie references.

[Marc] (7:22 - 8:30)

Yeah, there's a funny quote here. And, you know, as a fellow giant yourself, Darren, don't take this personally, but, you know, there, there was a statement that they made that it's easier to stand on the shoulders of giants if you kill them first, but you can't see as far. And, you know, it's, it was, it was kind of like, they had a lot of really funny kind of angles on things.

And one of the things that I like to point out here is there's an old saying that, like, I explained it once, and I explained it again. And then I started to understand it myself. And then I explained it no further.

It's like when you take the time to organize a talk, submit something to a call for papers, by the way, the call for papers for our London conference in March is open right now. But when you take the time to submit, you know, an idea to a call for papers, and then, oh my gosh, you might actually, you know, get an opportunity to go to the conference and present the thing. You will understand the work that you do through a thousand different eyes and through not only the experiences of the people around you, but by explaining it, you'll understand it more deeply than you can by just building it, creating it, and operating it.

[Darren] (8:30 - 9:14)

Yeah, I agree. The idea of this whole building a greater understanding was also something they brought up in their idea that you need to be able to translate tech into business. And I think this is where a lot of tech people, including myself fall down because they see things from the angle of pure tech.

And this kind of opened up this idea that, well, not opened it up. I'm sure lots of people know this, but tech is there to support the business and tech needs to be understood by the business. And that's how you get the buy-in.

That's how you get the push to build the platforms. That's how you get the things you need to progress. So, yeah, I think there were quite a lot of great takeaways from the looks on the day.

[Marc] (9:14 - 9:57)

And there was one more that I happen to be reading Richard Feynman's book at the moment again because it just kind of ended up on my nightstand. And there was a thing that he had, which is, you know, his problem-solving method was you write down the problem, you think really hard, and then you write down the solution. And there was something that Dan and Emma said, which is as engineers, we're focused on creating the solution and we forget to evaluate the problem first.

And they said, I believe their advice was spend a lot more time on the problem without the solutions. And then you can spend a little time on the solution and probably have a better one. Whereas as engineers, we're always focused on that damn solution, and we forget about the problem sometimes.

[Darren] (9:58 - 10:07)

Yeah, I think Emma broke that down in the best way of just keep asking why until you annoy everyone. And then you will understand your problem. Cool.

[Marc] (10:07 - 10:13)

Did you check out Bjorn and Supriya from IKEA talking about their transformation journey?

[Darren] (10:13 - 10:18)

I did, yeah. I guess you didn't get to go to those ones as you were hosting the opposite stage.

[Marc] (10:18 - 10:22)

Yeah, I was on the other track, but I talked with them about it.

[Darren] (10:22 - 11:30)

I mean, it was mostly interesting to see how IKEA have gone through the trouble of essentially templating everything they can to give this whole ecosystem, which is repeatable and duplicatable so that you can make. It basically was like a testament to how DevOps can work at scale. And obviously, we're seeing huge scale with something like IKEA and the toolchain they're using to support their stores.

So I think there was a lot of good takeaways there. It was more interesting from a perspective of how they solve things as kind of a story than having great technical takeaways or something like that. But the idea of there, they have this Alan portal, you know, based off their infamous keys and just how they bring the entire experience for developers together behind this single pane of glass is kind of, it's kind of stands as an example of how things should be done and maybe aren't all the time.

But it was good to see someone like doing things right and kind of nailing it.

[Marc] (11:30 - 11:54)

I love the idea of Alan. It's like most people, I always wondered, like, how did they come up with, like many people in, you know, kind of outside of the Anglosphere talk about a hex wrench. And, you know, I even say IKEA wrench in order to translate across, you know, kind of different languages and cultures sometimes.

But in the U.S., they were always called Alan Keys, which was a brand name, kind of like Kleenex or even Phillips.

[Darren] (11:54 - 12:08)

But I think it comes from the Swedish like that would be the Swedish word for the all, I think. So it would be like the all-key. So it's how they work.

It's the key to everything. The key to putting everything in IKEA together.

[Marc] (12:09 - 12:56)

Brilliant. On to Steve Pereira. What an individual! Steve is just absolutely prolific and capable to talk at many different kind of depths.

And, you know, talking about flow, this is something that is it's a huge part of developer experience, you know, enabling developer flow. And when we talk about process optimization, especially in, you know, in Agile systems, we talk about first optimizing for flow. You know, if you have flow from end to end, if you have the ability to take an item and deploy it, then you can optimize that flow.

And I think this even kind of ties back from some of the from the IKEA discussion about, you know, if you can template everything, you can make it a lot easier to flow as well. But what did you think of Steve?

[Darren] (12:57 - 13:57)

Well, he brought up one other subject, which I was kind of gratified by giving the final keynote. But he also talked quite a lot about mapping and talked about mapping being an excellent way to reconnect with your team. And like this idea of being able to put your ideas and your processes down on paper or obviously maybe not on paper.

He was quite adamant that you can map on anything. But the idea that mapping is a thing you should be building and should be doing was just so gratifying to hear when we put Simon Wardley on the stage last. So, yeah, Steve Perera was like a great speaker on this idea of, as you say, flow and just understanding, like what you say, the small subsection of what developers are actually doing to add value and not being caught up in business need.

But this pushing of flow and it was like, I don't know, it felt like it looped between Atlassian's talk and our keynote quite nicely.

[Marc] (13:57 - 14:58)

There's so many things here. In retrospectives, we talk about something that's good, something that's bad, something to change. And then we try to do things.

There's this blameless postmortem idea, which is sometimes not. But we try really hard to make it blameless. And one of the ways that I've been rephrasing this is what is slowing you down?

So then, value stream mapping as an exercise, one of the intrinsic values of value stream mapping is it's a way to communicate within your team and sometimes beyond your team. So saying that this is a way to connect with your team is spot on. And then being able to draw those things together, look at them, and say, why are we doing this?

Or this is the thing that slows me down the most. You know, oftentimes actions happen outside organically. But then being able to take these, look at them, point out and agree that this is a problem we should solve.

That's a hugely powerful thing.

[Darren] (14:59 - 15:32)

Yeah, yeah, it definitely is. And it also brings us up to this problem that people have been looking to solve for a couple of years now. We saw a DEF CON in Las Vegas quite recently.

But we also had Robin Newman on the stage talking about this idea of DevSecOps. So security in space. And obviously me being the security nerd, this was like a huge high point for me talking about what I think is kind of a cool work area in the coolest possible environment.

So, what did you think of Robin's talk?

[Marc] (15:33 - 17:30)

Oh, it made me homesick. Having been around a little bit around aerospace and type of defense people, usually as a consultant or a contractor, the way that people, you know, they have life in their hands. They have, you know, literally small teams working on things that cost billions like, you know, aerospace kind of technology.

The pride that they take, the dedication, the work ethic, and just the kind of matter of fact way of talking about the things. It's really cool. And Robin, she had so much depth of knowledge and experience when she came to the stage.

And then, you know, she brought us some goodies and some kind of, if you think space is cool, she thinks Formula One is super cool. And she told us that the fastest car on day one would not evolve every day. Then, they would lose the race.

So it shows about, you know, how much, you know, this kind of continuous improvement and continuous optimization is possible. When you have a goal, which is as black and white as winning a race, or, you know, as black and white as are we going to, you know, get the humans, you know, to space and back, something like that. But amazing.

And the thing that I love as well about something like an aerospace story at a DevOps conference is it shows that you know, no matter our level of compliance, no matter the difficulty of the problems we solve. We're all essentially looking at similar problems, and we're using similar tools and methodologies to solve them. Sometimes with, I hate the word maturity, capability, maybe with different levels of capability in our organizations.

But essentially, you know, you can use the same tool chain to send a message to the drone on Mars to take a software update as you would to be able to deploy to a SAS service up to a point.

[Darren] (17:30 - 18:10)

Yeah, it's like, I think we've said it before, the challenges don't change. The toolchains don't change. A lot of people's most unique problems are the problems that everyone else is facing, but they don't realize that because they exist inside their own company.

They don't have this visibility. So having Robin come and say, yeah, I'm working on security of these systems in space, and it's actually quite a lot like security of these systems elsewhere was, I hope, kind of eye-opening to people that it's not. These challenges aren't unique and a lot of our known solutions will work in a great deal of areas.

[Marc] (18:10 - 18:40)

All right, next up, we had Carlsberg in the house. And I had previously seen a talk from Carlsberg at GitHub Galaxy in London, where they have, they centralize basically everything into GitHub. They're using all the features and GitHub Advanced Security and Copilot and all the whatnot.

What did you think of Peter Birkholm Buch's presentation?

[Darren] (18:40 - 18:46)

Unfortunately, I wasn't able to see that one. So I'm having to wait for the recording. I'm looking forward to though.

I hear it was good.

[Marc] (18:46 - 20:10)

All right. There's one quote that I'll pull out of there, which I think was really neat, which is full stack platform engineers are as rare and valuable as dinosaur unicorns. So that's kind of stacking things up.

It actually, it leads to something that we'll get when we talk about the lightning talks. One of the things that came out in a lightning talk was, you know, you don't expect the plumbers to do carpenter's work. So why do you expect developers to do operations?

But we'll come on down there to that. I had the pleasure of hosting our CTO, Marko Klemetti, who did a live AI demonstration of some code that he had created only using AI. The previous weekend, he created a template for a react application and then a CLI.

And he used that CLI in order to create a new web app from scratch that allowed the members of the audience to pick up a QR code and vote on whether they think AI-driven tooling or platform engineering is the most important thing for them in the future. And then we got to watch it kind of move back and forth live in real-time. And he did a beautiful job, and it talked a lot about how the future is changing as an individual contributor in the face of AI.

[Darren] (20:10 - 21:19)

Yeah, I actually felt a little bit like there was the whole magician, a little bit too good for the crowd effect there. In the demonstration, I think, actually went over the head of a number of people of how cool the technology surrounding that was. Just because it was so smooth and like undramatic and very clean and very clear.

So there was this kind of effect where people didn't fully follow it in the way that I was sat there at the back thinking, well, that's impressive. And I think people just saw it as an app, but it's always cool to see Marko go on stage. He was, in my opinion, kind of challenging the maybe not challenging the dev X idea, but he did say if your organization spends only 10% of its time actually writing code, then reducing that by 55% with AI will only make your organization 5% faster.

And that's kind of a eye-opening thing to me because we spend all this time talking about developer experience and how powerful and profound it is. But we also need to be doing what we can to reduce everything outside of that to allow for more time to develop.

[Marc] (21:19 - 23:01)

And there's a really important point that came up here, and I'm going to rant about this yet again, that Agile was never intended to mean that every team does things differently with a different set of tools. And unfortunately, that's the way that many enterprises have empowered their development teams by saying you can work internally within the team, however, you want, and use whatever tools you want, which means so many things. But one thing that it doesn't mean is giving people really interesting problems to solve in a space where they feel safe to be able to experiment.

And what Marko said is as development decentralizes toolchains, centralize, or I'll put it differently. If you want to empower your teams as much as possible, give them a secure, compliant toolchain, and then they can solve interesting problems in much more innovative ways. There's something that I was talking about before going into Scandinavia, where consensus culture is a huge thing.

And I have been saying recently that consensus means that you're tying your forward progress to your slowest mover. Basically, it means you take your whole technology adoption curve, and you tie it to the laggard and say no early majority, no late majority kind of laggard thing. But really, to break through on this, it's like forcing the teams into a modern centralized toolchain and then let them grow.

So give them a good golden path kind of thing is one of the tenants that I think Marko was talking about, but certainly I am cheering for.

[Darren] (23:01 - 23:28)

Yeah, it always seems to come back to do everything you can to get out of the way of your developers so they can develop. I mean, the golden path is a nicer way to put it, but yeah. Then we had the lightning talks up next, which were, I'm always kind of impressed by the lightning talks and the ability to transmit all this information in five minutes.

We start off with Zander talking about platform engineering for startups.

[Marc] (23:29 - 24:07)

Yeah, this was a really hot topic. His title was something along the lines of laying trucks in front of a moving train. And the minimum viable platform was something that was really cool.

And it kind of goes against this consensus culture thing that I was talking about before. It's like, let's not worry about all the corner cases. Let's take a few of the main cases that are the most important and let's enable those in a logical manner, the templates and reusability.

And, you know, there's a lot of overhead of deploying applications, he said, but we don't know which ones we need to know, only that they will be different.

[Darren] (24:08 - 25:00)

Yeah, I'm just pleased that we have some space on our stage to cover this area that I think often gets left behind when we're, you know, pulling people like Atlassian, Microsoft onto the stage. It's kind of easy for this startup vision to get left behind. And yeah, the, having worked in startups in DevOps before, it's very much, I think the metaphor we used was rebuilding the engine of a plane before landing.

So you have this, this idea where you're in the air, and you're having to get to where you need to go and you need to be able to land when you get there. So it's like, it's saying these sustainable goals, these manageable goals and breaking it down. And as you say, ignoring consensus culture for coverage and seeing how much you can cover with the minimal resources you get as a startup.

[Marc] (25:01 - 27:15)

I have to connect this to a discussion in the hallway track where there was a company that, you know, a lot of the developers are kind of taking care of the internal tooling normal. They don't really feel like they're quite big enough yet for a platform team. So there was a discussion going on, and somebody pulled me in and said, you know, what's my advice?

And one of the things I said is, okay, what if I told you that the best part of scaled Agile framework is also the least used part. And then everybody kind of chuckles. And I said it's called the ideation sprint.

And then half of them said, what's that? And I said, you are using safe, aren't you? And said, yeah, yeah.

So taking time, one sprint every couple of weeks or every quarter or one day a week or every other week or something, but creating a time block in order to work on your tooling, your infrastructure, your ability to deliver. Sometimes your technical debt, but let's take it back to the platform to work on your platform for a little bit longer term cases than just, you know, being reactive or doing the minimum to keep the thing going. This is kind of one way.

Then we looked at in the beginning, there were communities and it was good. And then there was this idea, well, let's hold the communities accountable for something. And we had communities of practice.

And then we already realized that, okay, that's difficult. And then the community is like, can you just take your practice away and give me back my community? And then in the corporate world, we realized that, okay, there's a big trend now.

So we knew that if it becomes too big, we would need a team. So it's no longer a community of practice. It's a team.

But then now a lot of things that used to be communities of practice or sometimes even guilds and things like that become business areas. Right. So, okay.

Is platform engineering a business area? Maybe not, but it does have a logical evolution based upon our history to becoming a team. So if you're not there yet on the team, then how do you allocate time for it?

And how do you also make, you know, kind of a forward-looking improvement on it regularly?

[Darren] (27:15 - 27:31)

Yeah. It sounds like the case of we discussed before: Tech needs to serve business, but also in this case, business needs to serve tech. Business needs to ensure they have that.

And yeah, without them being a team, without them being if any kind of official standing, how do they do any of that?

[Marc] (27:31 - 28:34)

So Rasmus from Microsoft. Oh my God. This is, I think, the single greatest lightning talk I've ever seen.

No slouch to any of our others, but his title, why DevOps is failing enterprises. And he brought it all. And he brought every hypocrisy and pathology towards allowing enterprises to put things in the way of developer productivity, of software productivity, of psychological safety, of just being sensical.

So he lays it all out for us. I watched it again last night on the recording, laid it all out. And he said, we must take the fight to the CEO.

And I think that this is something that is one of the greatest things. You know, let's get rid of the IT department because IT is business. Business is IT.

And let's take the fight that in order to be successful, we have to invest in Developer Experience.

[Darren] (28:34 - 29:17)

Yeah. The talk was honestly, I don't want to explain too much because I think if there's one talk, you should go and watch like a hundred percent, go and watch the video for it's Rasmus's talk. And yeah, he in five minutes said so many things I never expected to hear out of the mouth of a Microsoft employee.

And I discussed this with him after the talk. And it's like the honesty and integrity out of it, just kind of hammering nails into these problematic areas, the plague of business was honestly kind of inspiring. So yeah, there's not much to say about this one.

Just watch it. It's five minutes and it's five minutes you need to spend.

[Marc] (29:19 - 30:05)

It's funny. We had a we had a little postmortem with a group of people. And, you know, when I grew up, I cannot say at any point specifically that I said, hey, Microsoft is cool.

But one of the coolest things that I've seen in our field came from a Microsoft person. And I tell you what, they're getting pretty chill, and so many good things coming from Microsoft these days. So, on to our own.

So Jess Fraser-Darling gave a lightning talk on DevOps not being just for developers. And I think she did such an astonishing job in once again, in five minutes to be able to kind of raise the bar for a whole conference. And I think that she really pulled it off.

[Darren] (30:05 - 30:44)

She did. And what was more impressive was the fact that she was following Rasmus, who I think she noted it herself, at least in Copenhagen. He delivered this great speech and then Jess came along and she equaled it.

And it was like, OK, that was incredibly impressive. So, yeah, and she had this like she was talking about the understanding of DevOps throughout companies and whether people have the same understanding of it, not just in like the industry itself, but inside companies, if people are seeing DevOps the same way and how we remove this inability to communicate.

[Marc] (30:44 - 31:22)

And I think the single most important question that any of us can ask essentially anyone in a product software IT type of organization is what is the biggest bottleneck in moving a feature to production? A lot of people won't know, but it's absolutely the right question. All right.

Then we had Henrik from Red Hats and a couple of really interesting things here. The first one is making sure that you have a sense of meaning and purpose. This is a huge thing that we've talked about a lot in the conference.

We're talking about a lot on a day to day basis is making sure that people have a sense of purpose.

[Darren] (31:23 - 32:58)

Yeah. And the thing he said that resonated with me was that open source isn't just code open source. And we had this discussion on a podcast episode where we're talking about the weird language surrounding open versus open source and people using the word open when they don't mean open source to confuse people and having Henrik kind of just lay it out.

Open source isn't just your code. It's a mentality. It's a way of doing things was it's nice to have someone like sit down and succinctly sum that up.

Really cool. Do we get to talk about like my personal favorite presentation now? Go for it.

I mean, I think after having her on the podcast, I had high expectations of Charity Majors for the actual day of. And she just exceeded them beyond anything I would have imagined. It was a fantastic talk about observability and basically understanding your software, like learning how to switch from this kind of monolithic logs metrics type observability to actually getting into your software, getting to know your software, and allowing it to communicate in a way that's helpful and a way that's traceable and useful.

And I'm probably going to be referring to that talk every time I'm talking to anyone about visibility and security for the near future, because it's just it's everything you need to do stuffed into one 40 minute presentation.

[Marc] (32:58 - 34:56)

The way I introduced her, it's like there's few people in this industry that not only were there and know the history and know why things were done the way that they were and know what's going on at the moment and know what's coming and be able to pull you out from in front of the train or just say, let's do things in the right way. Here is the right way. You have the opportunity to do that.

Now, the arbitrarily wide structured logs using your logs and your traces in order to understand if the software that you're deploying to production is behaving the way that you expect it to, keeping this tightly within the context of time and current cognition, being able to plan for. And I'm already thinking this with my production systems as well. How do you plan for being able to understand when I put this into production that I'm able to validate that the behavior that I expect is there, preferably even programmatically being able to kind of bypass this observability 1.0 and go straight to arbitrarily wide structured logs with a line item or a blob per event in your software. Really, really amazing. And just, there were so many things that she, she put in, you know, when you are not having, you know, a single source of truth, it's you, the human, who is the link between, you know, metrics and logs and all the different types of tools that you might be using in observability 1.0 and trying to make these correlations or causations of things. Just astonishing the depth of being able to understand your software and, therefore, be able to safely deploy it to production that she demonstrated.

It's just amazing.

[Darren] (34:56 - 35:38)

I do think she also did a great job of challenging these established ideas in the form of she acknowledged the whole person who's been there the longest is typically the best debugger. And the fact that we cling to that, not because it's right, but because of how good it feels to be in that, that position of, yeah, I know everything about this system because I've been tinkering it with, tinkering with it the longest and how bad that is for software development. How we need to avoid that mindset and, you know, move towards this idea that people can be newer, be curious and discover what's needed.

Kind of cutting out the invisible knowledge.

[Marc] (35:39 - 39:13)

Yeah. Metrics are a key to the past. Logs are a key to the future.

Um, the most curious one is the best debugger when you have good observability and, you know, I've seen this person, I've not been that person. And I've been the legacy guy before, but, you know, I've seen new people come into the organization and use the tools that we have created and be able to find problems that we hadn't noticed just because they're very curious. I think that's also one of your security mindset types of things that you're a very curious guy.

So if you have the information available, you're going to keep working until you find something. And then I've saved this for last. So shortly after seeing Simon Wardley on the sidewall cabin of smoke, he was sitting next to Helen Beal, Chairman of the Value Stream Management Consortium, among other things.

And next to us was Steve Pereira. And Simon has very strong data on what is a map and what a map means. And it has consistency of movement.

It has an anchor. And I was absolutely giddy, losing my mind, watching the two of them kind of duke it out. And it was then to get to hear him speak.

I watched it again last night. So I've seen it three times kind of serially within the last week. And this is something that everybody needs to look at and understand.

And I'm going to summarize one point from my heart that I learned this time, because I've hosted Simon a couple of years ago before at the global event. He was online then, so I didn't have his presence with me, which is he is a huge shadow and a huge presence. He casts a lot of light into as well.

But as technologies evolve and evolution is not equivalent to maturity and computing is a really good example because we had really great product computers. And then when they got to the cloud, it has yet evolved, but it has not necessarily matured. But as things evolve, new practices emerge and those practices then create new evolutionary paths or new technologies that then go on their own evolutionary paths.

So when we look at what's going on with prompt engineering, for example, he didn't talk about this specifically. I'm riffing here now. But if we look at, okay, so AI is a new technology that now has become practically commoditized.

It's software as a service, right? So new practices emerge, you know, Copilot or Duo-assisted coding, being able to use agents in your organization to look at all the available information you have to make it easier to write code or to perform testing. So, new practices that are emerging, and then those practices are then going to drive the evolution of new technology.

And we don't necessarily always know what they are yet. So when we look at how we can create code on top of legacy today or how we can, you know, have a conversation with a machine and use that conversation in order to create new value propositions that then we can implement. We don't yet know what's coming, but Simon told us that we know we must look out for it.

And that there are patterns that evolve throughout technology of any kind and they create new practices, and the new practices create new evolution for new technologies.

[Darren] (39:13 - 40:17)

And though I don't know, I, for example, think the new trend we're going to see is going to be this agent based systems where the AI is spinning up more AI and this kind of approach. But the data that Simon had just supporting the idea that these new practices will emerge; this prompt engineering will go through these areas of revision. It was kind of good to see it from a historical standpoint because a lot of our people are talking about the future, and obviously that's where we want to keep our focus.

But this kind of grounding experience at the end to show that all of this, they are just following trends. It was all just data. It's all occurrences that are being tracked is I think it was a good way to wrap up.

And I don't think there's much you can say about Simon Wadley's speeches, except you need to see it. It's just, it's a good talk. And if you don't know about Wadley mapping, it's a useful tool, and learning about it is well worth the 40 minutes it will cost you.

[Marc] (40:18 - 40:32)

And to be able to understand strategy, this is one of the most powerful and yet graspable tools that I've ever seen. This is truly the big hammer of strategic development.

[Darren] (40:32 - 40:36)

Yeah, just the ease of visualization it provides.

[Marc] (40:36 - 41:50)

All right. I'm just amazed that we're able to, you know, walk into a room anywhere in the world with these types of people and talk about ideas and raise the value of those ideas. And kind of have a united understanding of, you know, the possibilities that we all have.

And so much of these come down to making a better world for everyone. And I think that's a really important thing right now. All right.

We're going to have some more of these people on our podcast soon. And we've had several of them in the past, Helen Beal, Charity Majors, for example. So, thanks again for listening to the sauna.

And I encourage you to have a look at the DevOps Conference Scandinavia recordings. All the ones that we had just talked about are available already. So get out there and have a listen.

Thank you. Nice to talk to you again, Darren. Thanks, bye.

All right. Goodbye. We'll now tell you a little bit about who we are.

Hi, I'm Marc Dillon. I am a Principal Consultant at Eficode, specializing in platform engineering and enterprise transformations.

[Darren] (41:50 - 41:56)

Hey, I'm Darren Richardson, Security Architect at Eficode. And I work to ensure the security of our managed services offerings.

[Marc] (41:57 - 42:04)

If you like what you hear, please like, rate, and subscribe on your favorite podcast platform. It means the world to us.