Old software and IT systems are the backbone of our businesses. We cannot avoid legacy systems but modifying and upgrading them is often hard.
Join me, Richard Bown, as I talk to industry experts about everything from IT operations and software change and delivery techniques as well as creating and steering a software product vision. Find out about real-world IT and software delivery best practices that help industries of all kinds deliver more value on time to keep customers happy and to keep out legacy systems delivering value.
Join me as I take a people-first approach to building future-proof IT and software systems.
That One Script You Wrote is Now a Platform
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:
Youtube is here:
More resources here:
The QUEST for Better Software: Happier Teams and Happier Customers
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.
The Agile Manifestohttps://agilemanifesto.org/
The Five Ideals from the Unicorn Projecthttps://itrevolution.com/articles/five-ideals-of-devops/
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=IzqdZAYcwfY
Kent Beck’s Presentation about Refactoring and Cost of Upfront Design:
It’s a great talk and worth watching. Because it exposes the social side of software development.
Avoiding Legacy? DDD, Collaborative Architecture and Product Thinking with Nico Krijnen
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.
The DDD NL meetup:
Nico's workshops at DDD Europe:
Full-day workshop on June 6:
2h hands-on at the main conference:
Automating architecture validation for Java and .NET:
With an example of using it for a layered or onion architecture from one of Nico's workshops:
Nico's speaker profile & linkedin:
And an overview of some of the courses Nico gives through Luminis:
[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...
The Business of Legacy - Making Software Change Successful
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.
Check out this link for the map of the Books I mention in the podcast:
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 Forsgren
[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]
Interview with Jonathan Hall - Talking DevOps, Go and Continuous Delivery in Reverse
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.
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/
[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...
Emergent Architectures and Beating the Monolith
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."
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]