Loving Legacy

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-platformYoutube is here:https://www.youtube.com/watch?v=vxf8LPTr6tcMore 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.NOTESThe Agile Manifestohttps://agilemanifesto.org/The Five Ideals from the Unicorn Projecthttps://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.John Romero’s 10 Programming Principleshttps://www.youtube.com/watch?v=IzqdZAYcwfYhttps://github.com/anttiviljami/romero-programming-principleshttps://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.NOTESThe 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.ktNico'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...

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.NOTESCheck 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 BeckOut of the Crisis by W. Edwards DemingThe Phoenix Project and the Unicorn Project by Gene Kim et alTeam Topologies by Matthew Skelton and Manuel PaisThe Goal by Eli GoldrattCrossing the Chasm by Geoffrey A MooreWorking Effectively with Legacy Code by Michael FeathersObviously Awesome by April DunfordAccelerate by Nicole Forsgren, Jez Humble and Gene KimThe Value Flywheel Effect by David Anderson et alThe DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis and Nicole ForsgrenQUOTES[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.NOTESTiny DevOps Podcast: https://jhall.io/tinydevops/Cup o' Go Podcast: https://cupogo.dev/Adventures in DevOps Podcast: https://topenddevs.com/podcasts/adventures-in-devopsBoldy Go Youtube Channel: https://www.youtube.com/channel/UC79XhRzbR3YSnm3ODqgZ6EQBest 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...

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."NOTEShttps://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/QUOTES01: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.LINKSJAM websiteA 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!NOTESHow To Draw An Owl MemeSooner, Safer, Happier - Jonathan SmartObservability Engineering - Charity Majors et alAccelerate - Nicole Forsgren et alSlight 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.NOTESThe 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-performanceGetting Naked:https://www.amazon.com/Getting-Naked-Business-Shedding-Sabotage/dp/0787976393CodeScene:https://codescene.com/https://codescene.com/blog/author/adam-tornhillQUOTES[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]...

It's 2023 and just like any year, your timeline is awash with good intentions and lists of things that you can do this year. You might even be writing a list - but what is the good of a list if you never look at it and it's too big to comprehend in the first place?I use this episode to relaunch this channel as "Lovin' Legacy" - because I love legacy code and I'm not afraid to say it - and also to poke at the lists that the Agile Manifesto, John Romero and Gene Kim (and others) have made for us.Can we make sense out of the true core of software development - can we focus on just a few things?I hope we can.I unpack or at least uncover my own acronym called QUEST, which is all about making the software and team sing from the same hymn sheet. Let's start 2023 together with a bang. Hope you like this episode and the rebrand - let me know in the comments!NOTESThe Agile Manifestohttps://agilemanifesto.org/John Romero's 10 Programming Principles:https://www.youtube.com/watch?v=IzqdZAYcwfYGene Kim's Five Ideals:https://richardwbown.com/software-engineering-happiness-the-five-ideals/

Legacy and tech debt are a fact of life in all software. So how can we identify the major causes and try to limit them in our development process?This time I discuss the major causes of tech debt and put forward a way to deal with them at various levels in your organisation. Writing software is an intensely human activity and we'll deal with the factors that making writing perfect software next-to-impossible. For at least us humans.NOTEShttps://richardwbown.com/team-topologies/https://richardwbown.com/ddd-refactoring-and-legacy-code/Join my workshop on January 17th 2023:https://richardwbown.com/embracing-legacy-and-tech-debt

Before I read the book by Kent Beck I was just thinking - pesky tests what are they good for apart from getting in the way? What’s so good about Test Driven Development?But writing tests isn’t what test-driven development is about. It's actually about designing your code in a way that matches your expectations. It's a powerful technique that, when understood, will transform the way you write code and design software.NOTESKent Beck - Test Driven Development By Example:https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530Github template repository:https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-template-repositoryQUOTES00:54 - "Because TDD is not about driving development through testing. It's about designing and architecting your application. Through writing tests." [RB]02:12 - " I find myself going backwards and forwards, making sure I understood every single step and what it meant in that first section." [RB]03:26 - "And so you carry on writing some more code. And eventually the whole thing becomes a great big ball of string. Lots of code and no tests." [RB]04:06 - "It's more of a tool for a structured approach to design in the first place. " [RB]05:07 - "Writing a test helps show that it works. In fact, the word test is really wrong here. It's more of a proof than it is a test." [RB]06:06 - "Writing code in TDD can initially feel slow and labored but in only a short time, you'll start to notice the benefit." [RB]06:36 - "This is almost like the reverse Conway maneuver to Goldratt's theory of constraints." [RB]08:02 - "Whatever we do, there has to be a low barrier to entry for testing." [RB]08:42 - "And this is the true power of TDD, rather than agonizing over design and architecture and advance" [RB]09:12 - "TDD is an absolute no brainer" [RB]

Why do we love to build new code when we have plenty of good software that already works? Is the platform language or framework legacy? Is it because we want to learn a new skill? Is it because we are just bored of supporting the old software? I aim to persuade you that before you decide to rewrite even part of your application in a new language or framework, you can profit by making your existing code and existing deployments better and your organisation stronger.In this episode I equate Legacy and Tech Debt - they're the same thing at different scales - and I see them both as an immediate problem. As soon as you've written something you've incurred it. As soon as you've deployed it, you've incurred more. The attitude your engineering organisation takes to your codebase and your supporting systems speaks of your attitude to tech debt and legacy. If you can keep your code and your systems alive through constant attention - then you minimise the effects of the debt, and you minimise the chances that something becomes legacy.This was originally presented just this week at the ctocraft conference and I'm refining it in public as I go. Please let me know what you think and if my assumptions and potential conclusions are valid.NOTESLink to slides:https://richardwbown.com/wp-content/uploads/2022/11/Legacy-Code_-Sunk-Cost-or-Opportunity_.pdfLink to ctocraft conference: https://ctocraft.com/Link to my book list with the books mentioned: https://richardwbown.com/resources/QUOTES00:44 - "I equate legacy and technical debt to be the same thing at different scales " [RB]02:02 - "Wikipedia it has 15 categories of technical debt" [RB]02:27 - "Everything, every decision that we make incurs technical debt." [RB]03:19 - "it's always going to be built-in and assumptions around how we actually wants our software to do stuff" [RB]05:59 - " things only get complicated, of course, when we want to get users involved" [RB]07:07 - "our CI and our CD tools require configuration they require metadata. And a lot of the time we perhaps underestimate the amount of time that we have to spend in configuring these tools to be able to deliver what we want" [RB]07:19 - "Even with this simple pipeline, it becomes complex very soon" [RB]08:26 - "We want those teams to be able to work in that best possible way" [RB]08:59 - "And this is the essence of cognitive load. How can we take the stress away from the team so they can really perform at their best and provide a service, which our customers will love." [RB]09:24 - "Technical debt is what you feel the next time you want to make a change" [RB quoting Ward Cunningham]10:17 - "Something goes into production means we have legacy immediately." [RB]11:30 - "Legacy is also everywhere. In the enterprise, in the scale-up or in the startup and every major or minor decision we make" [RB]12:55 - "So often it's simpler for us to just ignore it. We put our heads in the sand" [RB]14:31 - "you must have a realistic plan to get to a new technology or get to a new application" [RB]16:25 - "if legacy is immediate, then engineers should always be invested in supporting business value. So how can we make that feeling happen?" [RB]17:07 - "everything that we do on a daily basis means value for customers. How can we achieve that feeling?" [RB]

Sparked by a short Twitter exchange, this time I investigate why a lot of CD implementations (that I've come across) often appear to be half-complete or just fail to achieve CD. What are the root drivers behind achieving CD and why do so many implementations fall short? Is it just ME?It's a hard subject and one that I've debated with quite a few people. This episode is an exploration of a few themes and perhaps can offer some insights or perhaps is still a work in progress. I certainly have a few more avenues to explore around where the application stops and the CD implementation begins - plus should you design your CD implementation with that in mind.Really interested to hear your thoughts.SHOW NOTESMy book list including links to 'Accelerate', 'Continuous Delivery' and Domain Driven Designhttps://richardwbown.com/resources/The original tweet:https://twitter.com/BryanFinster/status/1587589240321626113Original post with my quote and Bryan’s discussion of it:https://riseandfallofdevops.com/5-minute-devops-cd-is-pointless-5c906d0fd164Bryan discusses many things including “Engineer for Release” on the No Nonsense Podcast:https://richardwbown.com/bryan-finster-continuous-delivery-no-nonsense-podcast/QUOTES02:19 - "in my experience over 25 years working in software on it, I've rarely seen an organization successfully deploy a consistent CD implementation across the whole org." [RB]02:52 - "continuous delivery is often seen as a holy grail for a firm's digital transformation" [RB]04:42 - "the organization types should be Westrum generative. That it should be a nurturing, encouraging high cooperation organization" [RB]05:16 - "So my point is most orgs don't support the concept of CD because they don't change. " [RB]06:02 - "Because as every good book on the subject says without fail, there is no one size fits all solution for any of this. Plus it takes a lot of work on the journey is really, never complete. " [RB]07:16 - "Most organizations are not software delivery centered organizations. There's just something that they have to do" [RB]09:36 - "Pride gets in the way when it comes to building software, but also CD pipelines." [RB]11:10 - "CD typically is created by a few heroes who understand that complex domain." [RB]12:34 - "Similarly for CD, perhaps that's too lofty a goal to aim for directly. If we look at this huge program of work that we take on when we start to implement CD." [RB]14:07 - " where does. the application stop and where to CD begin. But that's a, that's a topic for another time I believe." [RB]15:47 - "engineering for release, which I really love. This is the concept that you're building your release mechanism even before you've built the first line of code." [RB]16:01 - "Before you even write a test or a single line of code, you write your pipeline" [RB]

What is legacy? What does it have to do with building new software? Why does it annoy us as software developers? Why does it worry us as business owners or product managers? Why do we ignore it as forward-lookers?  What’s so great about technology anyway that makes us do this?What exactly is legacy?  I believe that legacy software is not always the evil, boring thing that we believe it to be - and that before you decide on building a new software platform or product you should go through a process to define and refine your legacy and decide if building new is right for you.In this episode, I introduce some concepts about categorising and understanding your legacy systems.[[OR LeTS ReTIRE tHE MoNOLIth!!]]QUOTES01:09 - Step one for me is categorize your legacy under understanding the landscape. [RB]01:15 - If you have a system which is just not being used anymore, it's not legacy, that's just obsolete. [RB]02:23 - your company could be bearing its head in the sand and building something new to avoid looking at the real legacy problem. I call that ostrich legacy [RB]02:52 - This isn't a simple exercise. It is a strategic one to help you understand where you want to go with your business [RB]03:32 - The amount of investment or sunk cost made in a software product often puts us off from continuing to support it [RB]04:00 - This is the sunk cost fallacy fallacy. You had an idea that replacing what you had would somehow be a magical solution to all of your ongoing support and staffing issues. [RB]04:27 - But let's look at some of the other lies that we tell ourselves about new products. [RB]04:52 - We will finally be able to retire the monolith, and that is the real hum dinger. [RB]06:21 - We have heard good things about Kubernetes. We have been told that we need to cut costs. [RB]07:12 - There is a hidden complexity in bringing something to market. and this is the 80 20 rule [RB]07:46 - So rather than thinking about the sunk cost fallacy, think about the cost of ignoring legacy [RB]08:28 - It's a good idea to revisit your legacy categories and your landscape and try and work out how much it will change through the introduction of your new products or service [RB]09:35 - Take the time to continuously refine your picture of what makes up your product landscape and don't be afraid to make changes [RB]10:33 - Let's see how Elon Musk get on with his attempts to make Twitter a better platform. If you look at how that product has evolved, perhaps there are a few legacy products and systems there that he might want to think about. [RB]

An increasing number of businesses are now actually (at least partially) also software businesses. Energy companies, financial giants, insurers, and retailers – all of them have significant in-house developer populations numbering in the thousands or tens of thousands. These companies commission, buy and even build their own software. And these are not small or insignificant efforts. They are huge in many ways, interconnected through corporate IT as global IT infrastructure. It is hard to run and support all of this software using existing techniques.Tools and techniques are often fighting against what it means to be a software developer and provide little real value to the business either. It's time to reevaluate. It's time to take a new approach to how tools and techniques are applied in the industry when it comes to software delivery.SHOW NOTEShttps://richardwbown.com/a-manifesto-for-better-software-delivery/Global IT budget : https://www.zdnet.com/article/cloud-computing-security-or-more-developers-heres-where-the-tech-budget-is-being-spent-next/QUOTES00:44 "Building running and supporting software is hard. It's complicated for individuals and software companies alike" [RB]00:55 "An increasing number of businesses are now actually at least partially, also software businesses" [RB]01:33 "Everyone on the boards of these companies should be aware that building and delivering software is a difficult creative and fundamentally human process that they are undertaking." [RB]01:48 " Existing accepted techniques of project management have evolved when dealing with more predictable, externally managed vendor-run projects. " [RB]02:27 "The current patterns of agile lean and DevOps are definitely not new." [RB]02:49 "We talk sprints and time boxes, like we know what they mean."02:53 "The tools market alone is worth hundreds of billions of dollars annually" [RB]03:32 "Crazily most of these expensive tools like JIRA, Azure DevOps, github, gitlab, et cetera duplicate or replicate each other's features." [RB]04:05 "It's therefore insane to just buy a load of tools and think "job done"" [RB]04:36 "let's ensure that the whole organization understands, that when it comes to building software, all bets are off" [RB]05:09 "Get the tools out of the way. And back to being what they should be ,solutions to relieve us of the complicated manual processes and not self-justifying parts of the process themselves" [RB]

I talk to Tom Kennes, sustainable cloud consultant and ambassador for the Sustainable Digital Infrastructure Alliance (SDIA). We discuss how IT and software delivery can be more sustainable and what happens when Ronaldo uses Instagram. We also talked about the impact of programming language choice on carbon footprint, the amount of energy used when watching Netflix and how to right-size your cloud infrastructure. Lots to dive into for the techies with tools that are available to measure the impact of the software you build and deliver. The emphasis is very much on making small changes that add up to a big difference, so there are some really practical tips here for individuals and organisations.SHOW NOTESHow to join the SDIA:https://SDIA.io/joinMore on the the SDIA: https://sdialliance.org/ The Cloud Carbon Footprint Calculator: https://www.cloudcarbonfootprint.org/.  The most efficient programming languages:https://cryptomode.com/c-is-the-most-energy-efficient-and-fastest-programming-language-study-finds/AWS and Software Power Measurement https://medium.com/teads-engineering/estimating-aws-ec2-instances-power-consumption-c9745e347959 Scaphandre: https://github.com/hubblo-org/scaphandreRAPL: https://blog.chih.me/read-cpu-power-with-RAPL.htmlSolar-powered website: https://solar.lowtechmagazine.com/Instagram footprint for Ronaldo - actually a lot larger than Tom stated: https://www.gosports.com.my/news/high-energy-one-ronaldo-instagram-post-consumes-as-much-power-as-ten-households/ 1 hour of Netflix - newer research suggests lower numbers than Tom stated: https://www.carbonbrief.org/factcheck-what-is-the-carbon-footprint-of-streaming-video-on-netflix/. - Carbon Innumeracy. People tend to underestimate the amount of CO2 from a gallon of gasoline a lot: Amir, G. Carbon innumeracy. PLOS ONE 2018, 13, e0196282. https://www.researchgate.net/publication/324932129_Carbon_innumeracy/link/5aebc7ea0f7e9b01d3e0652f/downloadQUOTES2:05: "I think sustainability is, overall the best thing you can do. Anything that's more sustainable will, in the end benefit society." [TK]4:05 "First you think cloud is a good thing, (and) cloud is a good thing. Then you notice that there are some, oddities in there. They notice that why aren't we tackling those things?" [TK]4:33 "he real question here is how can we incentivize companies to start reporting on their digital footprint?" [TK]4:49 "cloud is the least welcome environment where you can measure these things" [TK]5:11 "sustainable IT attempts to enable companies and developers to start reporting on their GHG emissions, their carbon footprint, their

When was the last time you did a Minimal Viable Product that was actually minimal? How often do we get it right and truly focus on delivering something of value to the customer?On this week's podcast, I riff on the idea of how to get a true MVP, not only past the idea stage, but into production no matter what type of company you are. By looking at the constraints that we have in play at any one time, we can determine before we get started with an MVP how it might be rolled out.We also touch on the importance of marketing for your MVP and/or product – and ensuring that you have a customer base that wants it before you get there. How you can even use your compliance journey to road-test your idea.Join me for this discussion and, as always, let me know your thoughts about what’s gone wrong and what's gone right with your MVPs!SHOW NOTESThis show inspired by some systems thinking, some writing and also the theory of constraints.https://richardwbown.com/how-the-mvp-has-lost-its-meaning/https://en.wikipedia.org/wiki/Theory_of_constraintshttps://richardwbown.com/approvals-come-first/QUOTES00:49: “Much is made of the MVP, the minimal viable product. But so rarely is it executed in a meaningful and valuable way.”02:02: “Using an MVP to road-test new tech is not always a smart move.”03:19: “architecture just means big decisions that you're probably not going to undo later.”03:59: “There is a tension here between architecture and MVP”06:35 - “By narrowing our proposal for our MVP. We stand a greater chance of getting it approved and rolled out in order to gather feedback”07:28: “The reasoning behind the processes that build up around change control are all there for sensible reasons.”08:15: “Whatever of path is open to you, your MVP won't deliver unless it has users”08:49: “Don't leave the marketing to last or as an afterthought. And this applies not just to startups or individuals, but also to the scale-up or corporate world”

In this episode we explore the way that technology, tools and architecture can affect the product that you are building. As engineers do we need to think more about product side? As product marketers what can we do to understand how the technology choice informs or limits our product possibilities? How do we deliver software in an open source project vs how do we deliver software in a corporate banking environment? What are the constraints that we need to be aware of in our decisions and how the customer need informs that. How we need to enjoy what we’re building - and make sure that we continue to enjoy building it as an individual, a team or as a company.Once again I really enjoyed recording this one and asking myself some hard questions. Perhaps you have more questions that from it? Please get in touch with me via the Software Delivery Club. I’d love to hear from you!https://softwaredelivery.clubSHOW NOTESDave Farley - Modern Software Engineering (https://twitter.com/davefarley77):https://www.amazon.com/Modern-Software-Engineering-Discipline-Development/dp/0137314914April Dunford’s Obviously Awesome (https://twitter.com/aprildunford):https://www.aprildunford.com/obviously-awesomeRosegarden Linux Audio and Midi Sequencer and Notation Editor:http://rosegardenmusic.com/resources/authors/You can also download a compilation of my best blog posts in PDF form. I call it:A Systems Approach to Software Product Delivery

Making software is fun. Running software can be less fun. How do you do both and not go insane? How do you make sure you're not working all the time to keep your (virtual) baby up in the air?The same rules apply whether you're a startup, a scale-up, a corporate, an individual, an open source project contributor. You're part of your own support problem.This time I discuss what it's like to be a coder who wants to have it all - the good times and the bad times - but wants to limit the bad times to working hours only. I hope you enjoy it as much as I made recording it.NOTESXKCD 242 - The Difference:https://xkcd.com/242/Brian Scanlan about Intercom's approach to on call.https://www.intercom.com/blog/rapid-response-how-we-developed-an-on-call-team-at-intercom/And he talked about this recently on Adventures in DevOps:https://topenddevs.com/podcasts/adventures-in-devops/episodes/reducing-on-call-engineer-burnout-with-a-volunteer-management-infrastructure-devops-121Inspiring music that helped me write this:https://en.wikipedia.org/wiki/Milk_%26_Kisseshttps://en.wikipedia.org/wiki/Reading,_Writing_and_ArithmeticQUOTES01:25 - How did it feel the first time you wrote something in a computer language that maybe you just learned and it worked perhaps first time02:50 - We're in that space where creation is flowing. But at some point reality bites. Then we need to do something with this thing that we've created.5:05 - What is happening tonight? Mummy, why can't we go out to the zoo this weekend? I know guilt right. The point I'm really laboring here is that one should be proud of your creations.05:18 - All of our creations need us. All of these things are calling for our time.06:48 - Some of the most successful systems on the planet have been built on a knife edge of functional validity.07:43 - Your job is therefore to minimize that risk and ensure that you can roll back or fix forward with the least possible effort.09:21 - Be aware of your legacy as a coder. Think carefully about how your persisted data will be managed.