Lovin' Legacy Richard Bown

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]...

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!
NOTES
The Agile Manifesto
https://agilemanifesto.org/
John Romero's 10 Programming Principles:
https://www.youtube.com/watch?v=IzqdZAYcwfY
Gene 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.
NOTES
https://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