Loving Legacy

In this special episode I say hello after two years in silence, and I share what has been going on in the meantime.

I wrote a book. It's a novel. It's about how we treat each other at work, it's about families, friends, ambition, disappointment, mental health and the impact of 24/7/365 software culture and globalisation and AI on our workplace.

In this short episode I introduce you to the reasons behind writing the book and tease a continuation of this podcast.

You can find out more about the book on the Human Software Website.

If you'd like to hear more about the Rands Leadership Slack you can go here.

My blog called Surviving Software is still right here and you can also find me active on LinkedIn.

What is a platform? How does one appear and what do you do with it when you have one?

Exploring the line between planned organisational change and operational overhead. Overview of the state of platforms and introduction to Team Topologies concepts around Team API, Thinnest Viable Platform and Conway's Law.

Review of the talk I gave at the DevOops meetup in Amsterdam, November 22nd 2023.

Slides are here:

https://speakerdeck.com/bownie/that-one-script-you-wrote-is-now-a-platform

Youtube is here:

https://www.youtube.com/watch?v=vxf8LPTr6tc

More resources here:

https://richardwbown.com/that-one-script-you-wrote-is-a-now-a-platform/

To kick off a new season, I start with a deep dive into the QUEST framework-which-isn't-a-framework. QUEST is a mnemonic that helps you remember essential software delivery tasks. This previews my upcoming "We Are Developers" conference talk in Berlin 2023.

In this episode, I take a view on the Agile Manifesto, the 5 Ideals from the Unicorn Project as well as John Romero's 10 Programming Principles and rewrite them, group them and then provide you with a way to remember how to apply them (and what they mean) every single day whether in your team, for your teams, or your customer.

NOTES

https://agilemanifesto.org/

https://itrevolution.com/articles/five-ideals-of-devops/

https://richardwbown.com/software-engineering-happiness-the-five-ideals/

Scope: ensure that the team can work on a context over which they have complete control. See Team Topologies, see SOLID principles, see DDD.

Flow: Work in small batches with complete mastery of our domain.

Agility: Make our context better every day. Improve our experience.

Freedom: to experiment, to try without fear.

Delivery: provide solutions to customers with minimal possible overhead.

https://www.youtube.com/watch?v=IzqdZAYcwfY

https://github.com/anttiviljami/romero-programming-principles

https://richardwbown.com/john-romeros-ten-principles-for-building-great-software/

Kent Beck’s Presentation about Refactoring and Cost of Upfront Design:

https://www.infoq.com/presentations/refactoring-cleaning-code/

It’s a great talk and worth watching. Because it exposes the social side of software development.

QUOTES

Do you hate legacy or do you love it? Do you accept it or do you want to stamp it out? This time I talk to Nico Krijnen (Lumunis) about the opportunities we have in our legacy codebases to understand our business better, the strategic use of new technologies to make important product improvements, the importance of collaboration and visualisation to create a shared vision of software architecture and our product no matter what state the codebase or architecture.

We discuss the meaning of legacy, what it is and when it appears, how to fix it, how to avoid it and how to prosper as a business while replacing it. We also talk about what you can do in your pipelines to avoid legacy automatically, the importance of visualisation, context mapping in DDD and C4 diagrams.

In a fascinating and wide-ranging discussion, we talk about what it takes to make great software in the age of microservices.

NOTES

The DDD NL meetup:

https://www.meetup.com/domain-driven-design-nederland/

Nico's workshops at DDD Europe:

Full-day workshop on June 6:

https://dddeurope.academy/applied-eventstorming/

2h hands-on at the main conference:

https://2023.dddeurope.com/program/playing-with-domain-models-in-code/

Automating architecture validation for Java and .NET:

https://www.archunit.org/

https://archunitnet.readthedocs.io/en/latest/

With an example of using it for a layered or onion architecture from one of Nico's workshops:

https://github.com/nkrijnen/workshop-apeldoorn-jug-2022-11/blob/main/part-01/src/test/kotlin/eu/luminis/workshop/smallsteps/ArchitectureTest.kt

Nico's speaker profile & linkedin:

https://sessionize.com/nico-krijnen/

https://www.linkedin.com/in/nicokrijnen/

And an overview of some of the courses Nico gives through Luminis:

https://www.luminis.eu/expert/nico-krijnen/

QUOTES

[01:41] "it seems that in our industry, only seniors and architects, et cetera, are getting in touch with domain-driven design at some point and I think that's a waste" [NK]

[02:10] "so one of the things I really wanted to do is trying to lower that learning curve [for DDD]" [NK]

[04:03] "you need to have ways to create sort of a shared mental model of the stuff you're working on" [NK]

[05:02] "We had a chat the other night about, how we feel about Legacy. I said, I love it and you said, I hate it. How does the legacy fit into to your daily work?" [RB]

[06:20] "legacy can have a lot of bit different meanings, but typically it means something that's not, at least how I see it, is it's a code base or a product that's not easy to work with anymore." [NK]

[06:38] " I like to go fast. I like to, to build stuff and, and be excited about those things and not feel dragged down by, a big stone that you're dragging along." [NK]

[06:47] "that's why I hate it [..] but to be honest, all our industry is full of it" [NK]

[07:03] "a lot of teams do not have the discipline to then go fast, but also go quality" [NK]

[07:45] "So typically when you meet a legacy system, first of all, what, what are the smells of its legacy? And secondly, what would you start to think about doing to improve that situation?" [RB]

[08:59] "we got someone in and they started working fully automated regression test, so deploys to production could be done, [in] half an hour. So that's different from a week, right? " [NK]

[11:16] "Cause it's a system that's making money, right? This legacy system is the place where, where you, where your business runs on." [NK]

[11:55] "So, I still hate working with legacy, right?I refuse to accept it. I think that's more than mindset, right? So I refuse to accept it as legacy." [NK]

[12:50] "You can transform that into a modulith like, which is, uh, what you call it nowadays." [NK]

[14:09] "So that's also why I think why I'm talking at conferences and spreading this knowledge because I think it's important to help the industry to realize this and also to find ways to get [legacy] under control" [NK]

[14:23] "We're building more and more software and, if we're not doing it the right way, we're just building, a lot more legacy. And I don't want to be there!" [NK]

[15:06] "I think the ease with which organizations now adopt Kubernetes and under underestimate the complexity, [is] quite scary, to be honest." [NK]

[16:46] "I think in a lot of cases people underestimate the value of just sticking with the stuff that you know and can handle" [NK]

[17:34] "Because I think a big portion of legacy is that people don't understand how the system works or what it's supposed to do, or at least do, or pieces of it." [NK]

[17:49] "I think that's where domain driven design, again, has a good role to play, is that it helps you to understand a domain. It helps you to understand the problem space." [NK]

[18:24] "it's good to use some experimental technology to do something that nobody else has ever done because it's gonna put you in a space where nobody is and where you can solve problems that nobody else can solve." [NK]

[19:56] "I would try to take the Frankenstein out of it, not accept that it's a lost cause." [NK]

[21:00] "[Legacy] is usually the point where people don't understand how a system works anymore" [NK]

[22:25] "In the workshop you encounter something that's called an Arc Unit, which allows you in your pipeline check or you compile time or test time, check that the architecture that you have in mind is not violated" [NK]

[24:08] " I think is always super important to have at least one visual in your, in your project" [NK]

[24:53] "try to write the minimal amount that you can, right, that you need, but that you are sure that you can keep up to date over time" [NK]

[27:43] "the real value of that kind of high level diagram is not so much having an up-to date version of it. Is it It is drawing it together with the people working on it." [NK]

[29:11] "giving context , about a system, what I think is really useful to draw a context map like from DDD, which essentially is like the high level context overview of, a system, but then more focused on the communication patterns between systems and especially also between teams" [NK]

[30:24] "a high level C4 diagram and a context map" [NK]

[31:05] "The temptation is always for everybody to prove their worth on any project" [RB]

[31:50] "we don't want to get the impression [of domain driven design] that it means you start to do a lot of design upfront." [NK]

We are bombarded with the need for business change - which means systems change. At the same time, we need to be faster, safer and more secure than ever. How can you learn to make software delivery effortless, and how can you use the best knowledge on the planet to help you?

In this episode, I introduce the best books on software and IT change in business and how I would deliver effortless change dependent on context. If you want to know where to start tackling legacy systems change, start here.

NOTES

Check out this link for the map of the Books I mention in the podcast:

https://richardwbown.com/how-does-ability-to-innovate-impact-bottom-line/

• Domain Driven Design by Eric Evans (the blue book)
• Test Driven Development by Example by Kent Beck
• Out of the Crisis by W. Edwards Deming
• The Phoenix Project and the Unicorn Project by Gene Kim et al
• Team Topologies by Matthew Skelton and Manuel Pais
• The Goal by Eli Goldratt
• Crossing the Chasm by Geoffrey A Moore
• Working Effectively with Legacy Code by Michael Feathers
• Obviously Awesome by April Dunford
• Accelerate by Nicole Forsgren, Jez Humble and Gene Kim
• The Value Flywheel Effect by David Anderson et al
• The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis and Nicole Forsgren

QUOTES

[01:18] "So what is the secret glue that holds successful tech companies together and lets them succeed with it and software delivery where others fail?" [RB]

[01:55] "From what I can see, there is no secret to success in software change for your business. You need to be clear, consistent, pragmatic" [RB]

[02:22] "These are some of the lessons already distilled from the biggest and the best companies on the planet" [RB]

[02:37] "This, how quickly can your systems react and anticipate to changing market conditions? " [RB]

[03:47] "Almost anyone can manage IT and software delivery but the best always ask what appear to be on the surface, the most obscure, unrelated, or perhaps downright stupid questions." [RB]

[04:24] " it helps if you have a decent, wide base of technical knowledge before you start asking the questions" [RB]

[05:11] "So find the rough spots. Be an ear to those who are upset or disaffected or annoyed by how things are going now, and use their knowledge to inform your opinion" [RB]

[06:10] "At that point, no matter what the size or the shape of the system or the solution you're proposing, you'll be in a position to potentially deliver something that might make a difference to the business." [RB]

[06:43] "Ensuring that you have listened and understood is a priority. Then show how change can work for everyone and finally, show the results." [RB]

[07:10] "Therefore, it is not your change, it is the business' change, it is everybody's change" [RB]

[08:05] "I've put together a map of the best books that I feel contribute to this area, and I've also created a suggested path, which will help you navigate" [RB]

[09:41] "You can't afford to ignore product development as part of software development these days" [RB]

[10:59] "software deployment in a real life situation is always inevitably going to involve a legacy system or is going to involve a legacy decision that you've made on a previous deployment." [RB]

I talk to Jonathan Hall about all things DevOps from small companies to large companies and where the customer fits in the often technical story of our code development and deployment.

How do you bring junior devs up to speed responsibly? How do we as an industry think of DevOps tooling and how much is too much? How and when should you automate?

We also talk about his love for Golang and how it makes life simpler for junior and senior devs alike - how he got into DevOps and what that means to him both from a development and operations perspective.

Finally we also cover Continuous Delivery and how to implement more easily, in reverse.

NOTES

Tiny DevOps Podcast: https://jhall.io/tinydevops/

Cup o' Go Podcast: https://cupogo.dev/

Adventures in DevOps Podcast: https://topenddevs.com/podcasts/adventures-in-devops

Boldy Go Youtube Channel: https://www.youtube.com/channel/UC79XhRzbR3YSnm3ODqgZ6EQ

Best Book to Learn Go: https://boldlygo.tech/posts/2023-02-24-best-book-to-learn-go-in-2023/

Three Ways of DevOps: https://itrevolution.com/articles/the-three-ways-principles-underpinning-devops/

QUOTES

[02:41] "it was shortly after I joined that company that we had a Black Friday incident." [JH]

[03:02] "It turns out the problem was an execute bit had not been set on a little shell script." [JH]

[03:27] "how do we, how do we live a sane life. In a world where those mistakes are bound to happen" [JH]

[04:31] "any person who comes to realization, um, about themselves vis-a-vis software realizes that you have to limit mistakes as much as possible" [RB]

[05:45] "I was frequently frustrated by the, uh, The lack of streamlining they had around deployments" [JH]

[07:21] " So that's kind of how I realized. Tiny, in the sense of like small headcount, small teams is kind of where I wanted to focus." [JH]

[07:49] " if you're employee number 10, You have, you know, in theory, a 10% influence on how things are done. If you're employee number 1000, you have a 0.1% influence on how things are done. It's just a big difference that way." [JH]

[09:26] "I often say that the hardest part of our job isn't the technology, it's the people." [JH]

[11:24] "infinity sign with the different steps is one or the three ways of DevOps, and the customer doesn't really take a center seat in any of those, which is unfortunate." [JH]

[12:25] "one of the common things I see is people automating stuff before they even know what it's supposed to be doing" [JH]

[14:09] " I think that there's a natural human tendency to seek the easy answers." [JH]

[15:02] "The unfortunate truth is that life isn't that simple. Life isn't as simple." [JH]

[16:45] "since I tend to work more often with smaller, younger companies, one common piece of advice I often give them is to hire one senior instead of two juniors" [JH]

[17:33] "how many junior developers have you worked with who understood how Git works? That's an essential skill that is not being taught properly." [JH]

[18:19] "the less code you have, the safer your company is in the long run, the less expensive developers you need to maintain that code" [JH]

[18:55] "all these sorts of things you kind of pick up on the job, but that's 80% of the job really" [JH]

[20:54] "Dockers written and go" [JH]

[21:17] "So there's like 10 or 12 different ways to do loops in Pearl and go you have one and only one." [JH]

[26:15] "I've been making sort of an effort of educating people on the idea of implementing continuous delivery in reverse" [JH]

[27:29] "The problem with that approach is that nobody ever gets there, or almost nobody ever gets there." [JH]

[28:00] "Every time you push to either to master or to your staging branch or whatever you have there, get that automatic build and deploy working. Then after you have that in place, Start working backwards" [JH]

[29:27] "This makes the bottleneck more obvious. It makes the changes safer. It does introduce pain, but that pain can be a good thing if you use it to drive the right change." [JH]

[30:19] "Ask the question of Why can't you do that yet? Don't just stop there. " [JH]

[31:47] "10 years ago, it was, it was almost blasphemous to say that you could do 10 deploys in a day" [JH]

[32:11] " I'm encouraged by the, the way the conversation has changed over the last 10, 15 years." [JH]

What does it mean to support, extend or even replace a monolith and should we even try? This time I explore the landscape as it is now - when we feel under pressure to "do microservices" yet we have something that works but is perhaps too much of a monolith for us to work with effectively.

This quote from the end of the episode perhaps sums it up:

"Emergent architecture is used for understanding and extending complex systems, which have arrived at their state through an unknown path."

NOTES

https://richardwbown.com/build-now-vs-build-later-upfront-design-vs-implementation-costs/

https://richardwbown.com/beating-the-monolith-understanding-modern-software-delivery/

https://www.bol.com/nl/nl/f/domain-driven-design/9200000002151217/

https://richardwbown.com/defining-the-bounded-context-is-the-key-to-flow/

https://thenewstack.io/what-we-can-learn-from-twitters-outages/

QUOTES

01:25 - "emergent architecture is a smart way to say we built something and once we had a plan, but now we have to change it" [RB]

01:52 - "Documentation is of use in order for software archeologists to discover the business motivations for why we're built that way in the first place" [RB]

02:22 - "This is the very definition of the sunk cost fallacy. Those that have invested so much financially, emotionally, and reputationally, that they must double down on that approach until it's either universally accepted or until it's dead in the water. This approach, I call the "Abyss of Obsession", and it's a social construct" [RB]

03:19 - "it's important to dream big. We're all capable of it, and software is the perfect scaffolding for these dreams" [RB]

04:46 - "If you've ever tried to reverse engineer a system, then you will know that a complex system is exactly that, often intractable" [RB]

05:39 - "what you see from typical software projects is that either zero sum or significant upfront planning or design is made" [RB]

06:46 - "I call this cost to first 'gotcha'. The moment where we think, oh no, we forgot this fundamental thing" [RB]

08:07 - "Do not let our ideas become code." [RB]

09:41 - "Emergent architecture means that things change. We can be resilient to change, not just with how we build our applications physically, but also by expecting things to need to change." [RB]

10:30 - "This is why a legacy system is really every system we ever build" [RB]

11:03 - "I believe that just like a good domain model, we already have enough or perhaps too many words to describe the patterns that we see in enterprise systems and architecture." [RB]

12:02 - "Emergent architecture is used for understanding and extending complex systems, which have arrived at their state through an unknown path." [RB]

I talk to Dani Grant, the CEO and co-founder of Jam about their browser-based bug reporting solution and how it improves the bug-fixing experience for all those involved in reporting, triage and development. We discuss what challenges that Jam has faced in growing their product to 15k users with a small team of just 7 people and what the future might look like.

We talk about Jira, enterprise bug tracking and continuous engineering improvement when it comes to technical debt. We talk about working as a start-up and the challenges it brings when it comes to legacy architectural decisions as well as ways of improving code quality.

LINKS

JAM website

A link I like about MongoDB:) MongoDB is Web Scale

QUOTES

[01:23] "What we found holding us back is all of the miscommunication and back and forth. Bugs and fixes with engineers." [DG]

[02:11] "A screenshot is such a low-fidelity way to communicate something happening on the web" [DG]

[02:41] "with Jam, We try to get all of the relevant information for a developer all packaged into one link so they have all the information they need to debug right away, no back and forth needed. So it's one click to screenshot or record a video or instant replay, a bug that just happened and we grab a crop screenshot that you take plus the full screen. So all the contact you may have missed, um, plus console logs, fully inspectable network requests, and all the specs of the device and the browser and the operating system and even what your network speed was." [DG]

[04:36] "the first thing we wanted to do was just validate that this was not only a problem that we experienced as product managers at CloudFlare, but that this was a problem people experienced industry-wide" [DG]

[05:51] "we were really inspired. The story of Foursquare, the CEO bought himself a Learn PHP book, taught himself PHP to build the first version, and so we, we loved that story and, and wanted to emulate that." [DG]

[06:31] "we were very excited about the new technologies we could use to solve this problem. So we chose things like Kubernetes and GraphQL, and let me tell you that a couple years later, if there's ever any issue in our product, it is caused by one of the not boring technologies that we chose, like Kubernetes or GraphQL." [DG]

[08:08] "Boring old SQL comes to the rescue again" [RB]

[09:27] "Small team of seven. One thing we learned at CloudFlare is when something is important and you want it to go faster, it's actually better to have fewer people on it." [DG]

[10:51] "to be honest, the product managers, the support team members and the QA testers who are reporting bugs to engineers are just as frustrated. It's a communication problem, so it really has to be solved on both ends." [DG]

[12:36] "actually what we're seeing is that a lot of teams are sending jam to their customers and saying, we can't reproduce the bug you just reported. Please log it with this tool and then we'll be able to action it" [DG]

[18:07] "there's a lot of focus on engineering teams about how to, how to improve productivity, and there's a lot of talk about tooling. There's a lot of talk about collaboration with other teams. These things are awesome but I think that the bug reporting process has huge inefficiencies" [DG]

[20:02] "we realized we needed to build something that would improve the Jira experience from the inside out" [DG]

[24:00] "we feel like we're just getting started. There's so much to be done and I'm really excited about the future." [DG]

Not all engineers are equally invested in understanding what our software is actually doing - should they be and why? Is building a successful software product more than just a technical exercise in observability? How do we get more insights into the business direction of our product? Can we only truly test performance in production and what does that look like?

I talk to Stephen Townsend from Squared Up and the Slight Reliability podcast, all about SLOs and SREs and observability platforms and patterns and trying to predict what our customers want in the future.

This was a really in-depth and wide-ranging discussion and a lot of fun to put together. Hope you enjoy!

NOTES

How To Draw An Owl Meme

Sooner, Safer, Happier - Jonathan Smart

Observability Engineering - Charity Majors et al

Accelerate - Nicole Forsgren et al

Slight Reliability with Joey Hendricks (performance testing in production)

QUOTES

[03:19] "I've just come from a massive enterprise before and there was a massive disconnection between the day-to-day work or what's, what's on the minds of the people in those engineering teams versus the actual customers and the business." [ST]

[13:55] "It's a measure of how well you can understand and explain any state that your system can get into no matter how novel or bizarre" [ST quoting "Observability Engineering"]

[14:30] "now we're serverless and containers and all these ephemeral objects and well, they're being scattered everywhere. It's just hard to know what's happening" [ST]

[18:13] "investment in the customer experience for some is greater than for others" [RB]

[23:08] "Hey we are making technology changes. How does it change these other things?" [ST]

[25:37] "it's very weird to come from an engineering background and be talking about all these business objectives and things, but it's great" [ST]

[27:46] "if you're doing software observability, it needs to be thoughtful and continual. Like it can't be. We've set it up, we are done." [ST]

[34:33] "The most successful companies are doing that right now, and they're doing, they're following the best practices that we read about in all these great books, accelerate, et cetera, and DevOps handbook" [RB]

I talk to Jacob Lafors about his company, Verifa, as well as their approach to engagements around platform engineering, CI/CD and how he provides a value stream mapping service to clients. We talk about developer platforms and turning the developer experience into an internal product.

NOTES

The blog where inspiration for this podcast episode came from:

https://verifa.io/blog/unlock-your-continuous-delivery-potential-vsm/

Team Topologies:

https://teamtopologies.com/

DORA Metrics:

https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance

Getting Naked:

https://www.amazon.com/Getting-Naked-Business-Shedding-Sabotage/dp/0787976393

CodeScene:

https://codescene.com/

https://codescene.com/blog/author/adam-tornhill

QUOTES

[07:20] “How do we build a process that  helps bring value to the company?” [JL]

[10:04] “[CI/CD setup] It's really gonna depend on who you have in your team, your team size, the organization that you're part of as well” [JL]

[12:18] “The social technical side of software development is really coming to the fore now. I think it's not a moment too soon” [RB]

[13:02] (TT and Conway’s Law) “the way those technical decisions are made are so heavily influenced by the way the organizations and the teams around us are structured as well” [JL]

[13:20] “ And I think where that, that, that, that is going is, is more on the, the, the idea of platform engineering now” [JL]

[16:41] “and the reason why I don't get so annoyed when I hear these buzzwords because I think there's more to it than that.” [JL]

[18:09] “ if a platform team does extra work to cater for two people, it means that, or two personas, it means that those two personas have less work to do and that's much more scalable that one central team does the upfront work.” [JL]

[18:37] “you don't need to know Kubernetes. You can see the, the resources and you know, you can see one is green and one is red” [JL]

[21:00] On IDPs and product thinking: “getting that product mindset is, it's not difficult if you, if you've been building products before” [JL]

[24:03]  “ the problem we're solving is that we don't want the teams to have to manage and maintain all their own Kubernetes clusters” [JL]

[24:49] “usually the bigger the company and the bigger the teams  the general level of competence that you can assume does go down a little bit.” [JL]

[26:15] VALUE STREAM MAPPING

[26:34] “If I was brought in to build some kind of internal developer platform, the first thing I would go and do is to go and run, uh, value stream mapping workshops with the, with the different software teams.” [JL]

[28:00] “So what do you do? Do you, do you create a branch? Do you start hacking, coding?  What about when you get to, to use version control? and how's your merging process?” [JL]

[31:37] “if you're scared of losing your, your work or your contract or whatever because of what you're say and what you do, then, then, then you're not, you're not getting naked.” [JL]

[32:52] “I was kind of going through a funk at the time where I was like, continuous delivery is seen as a, again, as a hammer.” [RB]

[33:27] re: Continuous Delivery “there is no endgame and time is finite” [JL]

[34:07] “But I feel like for the justification value streams are very good because they produce this data for you.” [JL]

[34:51] “the DORA metrics are good. I wouldn't bother creating my own metrics just for the sake of having my own metrics” [JL]

[35:39] “I would know that if, if our business is very volatile and maybe we're quite young and you know, we need the product market fit and these sorts of things, then I would know that our key goals would be for changeability and, and adaptability and so on.” [JL]

[37:45] “You know, me and me and Bob over there, we got together and drew a value stream but didn't really help us.” [JL]

[37:57 ] “it's not just the diagram that's the value, it's the process of creating it, the process of getting people to talk, the process of, you know, that involvement with the team.” [JL]

[39:10]  “Well if your code doesn't change, then, then why are you cleaning up all these code smells?” [JL]

[40:57] “the DORA metrics aren't goals. I mean they don't tell you what to do.” [JL]