Clare: Hello and welcome to Making Tech Better, Made Tech’s fortnightly podcast bringing you content from all over the world, on how to improve your software delivery.
My name is Clare Sudbery, and my pronouns are, ‘she’ and ‘her’. I’ve been a software engineer for 21 years. I do a lot of speaking and writing on the topic of software delivery and I’m a Lead Engineer with Made Tech.
In this episode we came up against a new situation, which we haven’t encountered before, which was how to deal with swearing! I’m generally pretty sweary myself, so I didn’t even notice when our guest swore a few times during the interview, but it turns out that if we leave the swearwords in, we have to set the podcast as being “explicit” in Apple Podcasts, which can make it inaccessible to various people. So we’ve decided to follow the brilliant example of Mark Kermode and Simon Mayo in the BBC Film Review programme, and we’re going to use birdsong to replace the swearwords.
On Wednesday 19 May 2021, I spoke to Meri Williams. At Made Tech, we do a lot of work with public sector bodies who are working under GDS guidelines, that’s the Government Digital Service. Meri was part of the original GDS team. That tells me she’s going to know a lot about software delivery.
Clare: Hello Meri!
Meri: Hi Clare, nice to see you again, thanks for having me.
Clare: It’s a pleasure. Meri is the Chair of the Lead Developer Conference, which is how I know her. She is also – and this is my favourite thing – a Trustee at Stonewall, which is the UK’s leading LGBTQ+ rights charity. She is also an experienced CTO. I’m pretty sure that means that she has been CTO of more than one company, is that correct?
Clare: This is also amazing. I love seeing a female CTO, but not happy with just doing it once. How many times have you been a CTO?
Meri: Officially with the title, I have been CTO of a tiny healthcare start-up way back in the day. The more relevant ones are Moo, Monzo and I’m now at Helix, which is an AI driven company finding treatments for rare diseases.
Clare: Amazing. My first question is, who in this industry are you inspired by?
Meri: Quite a lot of people, actually. There’s a group of women leaders who I am particularly inspired by. Camille Fornier, Lara Hogan, Jessie Link, Maria Goutierez, Gina Trepani are all people I have had the good luck to hang out with in a kind of peer mentoring fashion. They are my group, they are my peer mentors and inspiration, and everything all rolled together, I suppose.
Clare: Wonderful. We’re going to be talking about bringing change to legacy systems, which I know is something that you’ve done a few times. What is your top three experiences of bringing change to legacy systems?
Meri: I joke sometimes that I’ve worked on systems so legacy they were probably vintage. I’ve worked on systems older than I was at the time. I started my career at Proctor and Gamble, it’s the world’s biggest consumer goods company. I worked early on there on a system that was literally running on a mainframe. If that mainframe had gone offline or powered down, there was no back up of the code, there was no way to rebuild the system.
Meri: There was a multi-billion-dollar operation reliant on a mainframe staying alive. It had not just one back up generator but two back up generators in the facility it was in. When I joined the company, the system was already ten years passed its originally planned decommission date.
There had been multiple attempts to replace it, to upgrade to something more standard but it was a bespoke system that had been developed. I worked on one part of that: the order, shipping, billing part of that coming out and into another system. I also worked as part of M & S digital on what was a very sad example of instant legacy. A very expensive, very long programme was done to build the new website. Not only did conversion halve when it went live, it essentially was already outdated at the point that it went live. So, a desktop only new website went live in early 2010s, which was not a great time to have a desktop only website.
My favourite moment in actually just building a modernisation layer on top of that, was when we were talking with some folks in the team. It’s not a shock that M & S’s client base is a little older than many other retailers. One of the questions we asked was, is there a lot of iPad use? There was a great amount of tablet use at the time, for 60 and up. They went, yeah, but we’re really lucky, we don’t see any iPad 1 anymore, it’s all iPad 2.
I brought an iPad 1 in the next day and tried to open the website on it and it crashed the iPad. It didn’t just crash the browser; it crashed the entire device. I said I think I’ve worked out why you don’t see much iPad 1 traffic. It’s actually that your website crashes the entire device.
The other major legacy programme that I worked on was much more understandable. When I was at Moo, Moo had grown very fast and quite organically. It was all good work, good people making the best choices they could under the circumstances they were in. But the company had grown to the point where it just wasn’t quite flexible enough. I think that’s a more typical start-up style story, where you start off building what’s needed, you add new features and eventually you get to a point where it’s just so complex and so intwined and such a ball of mud, as people say sometimes, that it’s very difficult for anybody new coming in to contribute effectively. That was much more of a refactor and overhaul kind of approach. I think the others were more big box systems, either replacing a big bespoke system or another big box system, in many cases.
Clare: Yes. The ball of mud – sorry, you’ve just distracted me – but the ball of mud analogy has always bothered me because people say ball of mud, and they nearly always show diagrams that look much more like balls of spaghetti.
Meri: Yes, or string.
Clare: I always think mud is a single, homogenous material. It doesn’t really signify complexity; it just signifies mud. I’ve never really got it. Why do people not just say spaghetti or string?
Meri: Yes, I agree with you, I’ve always found it a slightly weird term, but it is the term that is used, so I use it to.
Clare: Exactly, everybody knows what it means, even if it doesn’t actually make sense when you think about it.
Okay, I can’t remember where I saw it, I think it was on a slide from one of your talks. You talked about melting monoliths, which I really like. I really like that phrase. That’s kind of what we are describing here, isn’t it? Taking really large systems and breaking them down. One of the things you said is that when you are doing that, there are three types of challenge. There’s technical, cultural and process. Let’s start with technical. What are the typical technical issues that you face when you are melting a monolith?
Meri: Usually just that there is a lot of context missing, actually. One of my very favourite tools in the whole world is architectural decision records. I think if you can get into the habit with your team of writing down not what you did, but the why. What was the context you were in, why did you make this choice and what happened?
That has taught me that essentially, any time I’ve had access to the people who worked on that legacy system earlier on, you find out that things make sense. There was some constraint, there was some circumstance, there was some weird business process, there was some particular stakeholder requirement. There is always a decent reason. I genuinely believe that most people want to do well at their job, and they come to work every day trying to do the best that they can.
I think it’s very easy for us to look at a messy code base or a legacy system and dismiss everybody who came before us as idiots. It’s too easy and it’s done too often, in our industry, to be blunt.
Meri: I tend to go with the approach of saying this made sense at the time, how do we figure out where the circumstances and constraints have changed sufficiently that we can change it to what we think would look better now? Some of that is architectural change. A lot of it tends to be whether you go for microservices or whatever. Separation of concerns, clear interfaces between things and ideally, a testable API between most things. Because if you can get to the point of having a really good test suite at the boundary of something, then you can pretty much change whatever you like below the line. As long as it keeps responding in the same way that everything else expects, then you’re okay.
Where you’ve ended up with all of your business logic and your data and your presentation all in one place, it’s very hard to get that sort of separation of concerns. The technical challenges are mostly understanding what was done and why it was done, and not finding out after you’ve re-implemented or refactored, that weird thing was that way for a reason, and that reason still exists. Oh no, we’ve messed up the end of year accounting for the entire company! I think it just makes such a difference if you, with a team, go, let’s trust that they were doing the best they could in the circumstances they were in. Getting to the underlying why of the legacy system is the most important thing. Then clear separation of concerns, being able to attack the problem piece by piece, and trust that you’re not going to mess everything else up.
I think the worst rebuilds and refactors are the ones that try and go in parallel and then try and do a big bang cutover. It’s very, very difficult to do that effectively. It’s sometimes inescapable. In particular with finance systems, because you can’t really have your books distributed over more than one system for very long. You do end up sometimes having to do a hard cutover. People try but it doesn’t go very well. I think being aware of those real-life constraints, and then figuring out how you make this more bite size – what’s the smallest thing that you can change and learn from? How do you go from there? That’s the biggest thing technically.
Culturally, I think a lot of it is about believing that the people who came before you weren’t muppets. A lot of that comes from leadership in the team, but also willingness to realise that the code that is running is the code delivering value. As software developers, our focus is often very much on the building, but all the value that is delivered is when things are running.
I’ve ended up quite drawn to operations, particularly roles where I am responsible for operations that have some physical component as well. In a lot of my career – I loved, at Moo, having the manufacturing systems and shipping systems as well. I got to work on that kind of stuff at P & G too, and even at Monzo, there were physical cards being sent out and so on. So, I think bringing what a decade ago was talked about as the Dev Ops revolution, which my friend Nick Stenning says, if you put an announcement out saying that you need to hire a Dev Ops Engineer, he knows immediately you have at least three problems. Because there’s no such thing as a Dev Ops Engineer, you think you only need one of them, and you are clearly thinking about it as a separate team. You’ve failed on three fronts already.
Helping teams realise that the value is delivered when things are live, when things are in production, and caring just as much about things that are running, even if they are a bit inelegant or a bit muddy, as we said earlier.
Process is really interesting. There is a real temptation, when people are running legacy systems, to also change up all the processes. To change the way of doing things. I have literally never seen – and I’m a bit battle scarred at this point, I’ve seen quite a lot – I genuinely don’t think I’ve seen a time where somebody did a major process change at the same time as a major systems change, and it worked. But it’s very tempting. It’s what people want to do but it almost never goes well.
Clare: And why do you think that is?
Meri: There’s a quote, and I’m not going to be able to remember how to attribute it correctly, so apologies in advance. But essentially, it’s that the only complex systems that work evolve from simple systems that work. Nobody ever designs a complex system from a blank sheet of paper, that works immediately. I think that’s the problem. People iron out what is and isn’t going to work in a process much better, when they are doing it manually. Because then they can see that the process is the problem.
I’m not saying that you have to go back to actual pieces of paper, but most people can’t separate at all, whether it’s the software or the process or the way that the process has been implemented in the software.
Meri: What tends to work best is you get people to adapt their process in their current system, or do it in no system at all, or in Excel – the true business system of pretty much every business in the world. Then from there, once it works, then you add tech. Once it works, then you streamline.
Clare: Yes, because of course, the original lean idea was that you don’t start with a website or an app, you often start with pieces of paper or spreadsheets. You work out what works and then you build the tech. Once you’ve worked out whether people even want this thing, how they want to use it.
Meri: Yes. It’s been wonderful over the last decade or so, to see service design really coming to the fore a lot more. Lou Down has written a fantastic book called Good Services. I think they are now running pretty amazing training, as well, which is worth looking into if you haven’t got anybody in your team trained in service design yet.
One of the articles that I remember reading, that I just found wonderful and inspirational and a wonderful illustration of why that kind of thinking matters, is a post called the – the easiest way to find it is to search for the Blue and White Marbles post. It was essentially somebody going in I think to a government department, and literally representing every single query or bit of work that team did with a marble. White marbles were when it was a true request, so it’s somebody applying for a benefit or whatever else. A blue marble was when they were calling up because something had gone wrong in the process.
Meri: As they filled this up it was obvious that actually, there was plenty of capacity if things had been done right first time. The problem was that there was so much additional demand created by things going wrong, by people feeling they had to call up three times, or they put their request in twice because they didn’t trust that it was being worked on and that kind of stuff. It’s one of my favourite examples of that much broader thinking because probably anybody else would have just gone, we’re not getting enough done because people are clearly overworked, we need to double the team. But actually, they didn’t, they just needed to reduce the error rate, and enable the team to work on getting things right first time. Which they desperately wanted to do, right?
Clare: Of course.
Meri: Because again, most people want to do well at their job.
Clare: Yes. So, going back to technical issues, one of the things you might want to do while you are bringing change to legacy tech, is you might want to address a release cycle. I know this is something you have opinions on, so I’m just going to ask you a deliberate question designed to get you talking. Why is it, Meri, that releasing faster reduces risk?
Meri: I think regular releases always reduce risk. I’ll tell you an anecdote that may illustrate it better. I think I was the first person I know of, anyway, to move to an agile release approach with SAP. Earlier in my career, I had a bunch of financial systems for Proctor and Gamble in SAP.
Clare: Remind us of what SAP stands for?
Meri: I think it’s a German acronym maybe. It’s a big enterprise system, essentially. Most big companies in the world probably have SAPs somewhere in the centre of them. It’s a big, complicated beast, essentially. It’s also the only time that being able to speak German has helped my coding, because it’s a lot easier to develop in ABAP, which is SAP’s only bespoke coding language. If you can speak German, you can understand what is trying to be achieved in it.
Clare: Wow, I didn’t know that. I’ve never worked on an SAP system.
Meri: Yeah. So, I joined this team as the owner for a fairly significant chunk of these finance systems. At the time I joined, I think they might have been on a six-monthly release cycle. There was a two-month testing window before the release. The two months prior to that, everything people had been able to fit in with the team of 10+ developers, and a big, long list from the customers had been built. Then when you were testing, it could have been any of those changes that had messed everything up. That’s the fundamental thing, if you have to do two months of manual testing, you are going to group a load of stuff together. It makes it more likely that things are going to go wrong, you’re going to have more bugs, they are going to be harder to track down. When you find them, you’re going to find it harder to fix them.
We moved to releasing every three months, and then every month. The number of critical incidents, major incidents and minor incidents that were caused by releases went from in the previous year, over 100 critical and major incidents, to in the following year – we definitely went down to monthly releases, we might even have got to fortnightly – one critical incident and two majors.
Meri: It was literally that scale of difference. We were just having to test the thing that we had changed. We had a set of regression tests and we automated more of them. A lot of this is the stuff that feels unsexy to people, but it just makes such a difference. When you can find anything major that’s broken, it frees you up to be more daring but also safer in a very real way.
When I was at the Government Digital Service, to help build the team that built Gov.uk, the conversation with a bunch of very traditional IT people who thought that an annual release was the safest thing to do. Gov.uk releases a dozen times a day. Probably even hundreds, at this point, a decade on.
Clare: That’s fantastic. When you think about the contrast from once a year to dozens of times a day, that’s just astonishing, isn’t it? So, what would your ideal be? You mentioned before you got it down from every six months to every two weeks, but now you are talking about dozens of times a day. What would you ideally like to have?
Meri: I think a lot depends on the specifics of the system and the business. It needs to be big enough to be a meaningful improvement for users, but it needs to be small enough that you are very, very sure what you are testing. If you’ve got an automated test suite, you can then trust that you are not breaking anything else by accident.
I think that web as a paradigm is very well suited to that. It’s fantastic and you often have blue green deployments, and you have canaries, and you have A/B testing, so you are not changing everything for everybody in the middle of a journey. You’ve got all of these ways of making it less disruptive for users. I think when you expand your view and you have finance systems, people don’t want their apps to need to be updated every five minutes. It’s annoying if you want to get into your banking app and it’s, just a minute, we need to download some stuff. So, I’ve become a bit less zealous about it, I suppose, than I used to be.
Clare: Yes, okay. It’s a big change in working, isn’t it? It’s a big shock. Particularly if you’re going from something like once every six months to several times a day. You’re not just doing the same thing but more often. The way that you structure things is completely different. What do you need in place to be able to release several times a day? Or even several times a week?
Meri: A combination of things. Generally, you need regression testing you can rely on and run pretty fast. You need an appropriate test pyramid. Not the ice cream cone of tests, which Becky Stafford taught me was the state in most legacy systems, which is hardly any unit tests. So, if you imagine an ice cream cone, the tiny triangle at the bottom is the almost non-existent unit tests, then some end-to-end feature tests, then a lot of probably manual integration tests. Then a whole bunch of other stuff *BLEEP* people do because something went wrong before. The first thing I do, joining a new, big company, is I ask for the CAB checklist. CAB is a change approval board. Almost every big company has got one. The CAB checklist is the scar tissue of the organisation. Every time there is something really big, somebody does a debrief and they add another question to the CAB list. Let’s make sure the thing that happened already never happens again!
So, good testing, automation of that testing. Ideally, the ability to get a really rapid feedback loop. As a developer, you want to be able to run tests and have feedback, certainly faster than fetching a cup of coffee would take. You’d need a good source version control. I think GIT is one of the things that has really revolutionised things. A lot of people can’t even imagine the world we were in when we only had SVN, and we only had CVS. For folks listening who haven’t experienced this, it’s like developing on SharePoint. You had to check out the file that you wanted to change, and then only you could work on it. Then you’d put it back.
Clare: I remember that, yes!
Meri: And if somebody else had done a change to the same file, there was no way to merge your changes, so you ended up arguing about who had done more work. It was awful, awful. I remember actually, Joel Spolsky who founded Trello and Fog Creek and similar, he used to write, probably still does write a blog called Joel on Software. I remember him writing about how distributed source control might really be the thing that changed the industry, and he was right. It really, really was.
So, good testing, good source control, good deployment mechanisms, then all of the observability stuff afterwards, so that you can see if something goes wrong. I think that observability part is where the industry has moved a lot in the last five years. We used to talk almost separately about logging, monitoring, and alerting. This view that you of course need logging, monitoring, and alerting but what you really need is to spot when things go wrong. If you can spot that something is not right and fix it quite rapidly, that’s almost as good as catching it ahead of time, in most cases.
Clare: Yes, absolutely.
Clare: While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry, I am quite choosy about who I’ll work for. Made Tech are software delivery experts with high technical standards. We work almost exclusively with the public sector. We have an open-source employee handbook on GitHub, which I love. We have unlimited annual leave. What I love most about Made Tech is the people. They’ve got such passion to make a difference and they really care for each other.
Our Twitter handle is Made Tech, M-A-D-E-T-E-C-H. If you go to madetech.com/resources/books, you’ll find that we have a couple of free books available; Modernising Legacy Applications in the Public Sector and Building High Performance Agile Teams. We are currently recruiting in London, Bristol, South Wales, and the North of England via our Manchester Office. If you go to madetech.com/careers, you can find out more about that.
If you join our mailing list, you’ll get extra podcast content as well as finding out more about Made Tech. You’ll find a link in the description.
Clare: Before we return to the interview, just a quick reminder that before the break, we were talking about the benefits of frequent software releases but also, what you need in place in order to make that work. Things such as distributive source control and good observability.
Clare: Going back to culture, it’s not unusual for there to be a combative attitude between dev teams and change approval boards. How do you avoid that?
Meri: I think by recognising that the incentives are really, really different. Often, in the kind of organisations that have change approval boards, they also have a completely separate Ops team. They have a team that runs the systems, where all the value is, actually, as we talked about earlier. They are really just rewarded for nothing ever going wrong. Then you have a Dev team that are only ever rewarded for changes. Which is the biggest time where something is going to go wrong. Recognising that it is very difficult for two groups that are so differently incentivised and so differently valued to come into alignment, is the first step.
I remember working at M & S and my team, if we caused an issue, we would go and sit in the Ops room and make sure we fixed it. If that meant staying until 2.00am, we would do it. You have to show folks that you care about what they care about too. Because actually, there is nobody in an Ops team who doesn’t want things to improve for the customers. They are just thinking that the customer is going to be more unhappy if they can’t do their shopping, than if that feature is live. A lot of it is about reducing the throwing it over the wall aspect. A lot of the change in the last 10 or 15 years has been to have a you-run-what-you-build attitude. So, have teams that build software also responsible for it when it’s live. I think that’s very smart. You should put the pain with the people who cause it.
Very quickly, if you are being woken up every night because of something you and your team put live is screwing up the warehouse, or causing trucks to be backed up outside of a depot – these things really happen, right? They are real. So, if you get called out of bed at 2.00am every night for seven days, you fix that bug. You roll back the release. Whereas, if it’s somebody else getting woken up, it’s really disruptive for people to have that kind of disturbance, right? Part of it is about developers and engineers assuming responsibility for things when they are in production. By showing that level of responsibility, that level of caring, that’s how you start to gain the trust of CABs, of Ops teams. Because bluntly, they have a much harder job than we do, already. Running a big, complex system which often has millions of customers using it directly, is very tough as a job.
I think it starts with respect, with role modelling that an issue in production is our problem too. One of the things that changed that culture between Dev and Ops, certainly in that role at M & S Digital, was that we would go and be with them. When we had caused a problem we would go and sit with them, we would be coding the fix and getting it live as quickly as humanly possible. If the most useful thing that I could do in the moment was get food for everybody who was having to stay late in the Ops room to fix something, then that’s what we did. It’s that kind of stuff that weirdly, is the most important, culturally. It’s not anybody making a big announcement, or moving the two groups under the same leader, none of that. It’s about really, on the ground, do people know that you care a lot if you make their life harder, and you will do everything you can to undo it and you won’t make the same mistake again.
I think that’s the unforgivable thing, if you just screw up and then do the same thing the next week. Of course, they are not going to trust you. You are the chaos that is messing with the customer experience at that point. They are right to try and protect the customer from you.
Clare: I think the key there is bringing people together, isn’t it? So, they can see what each other are doing and see it from each other’s point of view. Because if there is a barrier, if there’s a wall between two teams, they don’t understand what the pain is that is being caused and what it is that they are trying to avoid. But if they are both there at the same time, then they are seeing that this is why, this is what’s causing pain, this is why these people are wary. This is what they are worried about. Again, even just removing those barriers altogether. You talked about Dev Ops before, so that devs are responsible for the ops and they actually know what that feels like.
I think there is a parallel there, as well, with a certain form of user testing, where you give users whatever your product is, let’s say it’s a website, you get them to interact with it and you get the devs to actually watch them interact with it. And understand why it is that they can’t find that button and they don’t understand what that widget is supposed to do. It’s not because they are stupid, they just have a different view of things.
Meri: There is nothing more humbling than watching users use the thing you built, nothing. I have been in the interesting position of being the chaotic user as well. When I worked at a tiny healthcare start-up, I had an absolutely brilliant – Emily Oswald, who was the Primary Dev, she would watch me using it, watch me using the app we were building. She would just be like; how do you not know that you should tap here rather than there when you are using this modal one on iPhone? She used to refer to it as the CTO breaking test. She’d be like, there’s a new one ready that you’re probably going to screw up but giving it to you is definitely a stress test. And just because I clearly wasn’t using the phone the way that was expected…
I have had somebody, quite a good friend of mine actually, Jessie Link who is at Twitter, she’s a drummer. Apparently, there are two ways to hold drumsticks. If you do it one way, then the other way looks really weird to you. I use my phone held in one hand, with the thumb of one hand and the thumb and forefinger of the other hand. Apparently, it looks very strange to people, but it’s because I’ve got some weird hypermobility in my hands because of the rare disease that I’ve got.
Clare: I remember my children poking fun at me because I use the phone like an old person. Apparently, you can tell. There is a generational difference. People my age, when they interact with their phones, they stab at it a lot with their forefinger, just one forefinger and not both thumbs. Another thing that shows my age is that I learned how to use a mouse as an adult, and it was horrible. I couldn’t control it, it was going all over the place, it wasn’t going where I wanted it to go. I can still remember what that felt like, that this thing that seems obvious when you have done it since you were two, is a skill that you have to learn.
Meri: Yes. My cousin is also in tech, and we were in South Africa, and we were visiting when his little boy was about two years old. I remember the first time the little boy sat on my lap and used my iPad. The next morning, he went over to his dad, who was sat working on his laptop. He tried to move something on the screen and when it didn’t work, he just slammed the laptop closed on my cousin’s fingers. He was like, this is your doing, isn’t it? You’ve shown him shinier tech than I have, and now he believes that every screen should be a touchscreen.
Clare: Now you are reminding me of a particular unique experience that only parents will know about, which is sticky touch screens. Not just sticky but caked in food and grot and God knows what, because your child is just carrying their iPad around with them everywhere. So horrible, yuck!
Clare: Okay, gosh, time has moved on apace. So, I’m going to ask you to tell me one thing about you that’s true, and one thing that is untrue. Don’t tell me which is which.
Meri: Can I give you three, two true and one false?
Clare: Yes, okay, that’s even better.
Meri: Something I soldered went into space. I speak seven languages and I am covered in tattoos. Two truths and a lie.
Clare: So, you soldered something that went into space. Can I ask you what it was?
Meri: It was an experiment on a satellite.
Clare: An experiment on a satellite? Wow!
Meri: It was essentially two circuit boards, one outside exposed to space, and one on the inside of the satellite, so that we could monitor over a longer period, what the impact of radiation and space debris and that kind of stuff was on the two sides of it.
Clare: What are the seven languages that you speak?
Meri: That is going into a lot of detail very quickly. What would your guess be?
Clare: Okay, well, I know that you grew up in South Africa, is that correct?
Meri: Yes, that’s right.
Clare: So, I’m going to say Afrikaans, English. I know that you are currently living in Crete, so I’m going to say Greek. French and German just because they are the ones I learned at school – is that five now?
Clare: And Russian and Chinese.
Meri: I don’t speak Greek, French, Russian or Mandarin or Cantonese.
Clare: Yes, sorry.
Meri: But I am living in Crete, and I do need to hurry up and learn more than my Kalimera, Kalispera, which is about the extent of my Greek at the moment. I need to learn the alphabet first, that’s the challenge. Anything with the Roman alphabet, I am better at.
Clare: When I was in Greece, I worked out why people say, ‘It’s all Greek to me.’ I’m quite good with languages and I speak French and German, and I can often pick up other languages, just from what I know from English, French, and German. But with Greek, there are just no clues. There’s nothing. The alphabet was completely bewildering. I have since tried to learn Greek using Duolingo. It is hard.
Meri: I process information much better by writing. I’m not visual at time. I’m a phantaisic, I can’t make pictures at all. So, I think I need to buy almost like a kid’s handwriting exercise book and that will be the way I manage to learn the alphabet.
Clare: Yes, cool, okay. So, what is the best thing that has happened to you in the last month or so, to end on a high?
Meri: The sea temperature in Crete has finally returned to swimmable levels. So, I can swim much more frequently, which is why I have ended up in Crete in the first place. Partly that, and partly that Brexit happened, and I wanted to be able to work and operate in Europe, so I exercised my EU rights while I still had them last year, so that I could move here. I have a disease called Ehlers Danlos syndrome. In lockdown in the UK, it got very difficult to manage because I need lots of physio, lots of hands-on treatment, which obviously wasn’t safe to do in the early days of Covid. So being able to swim regularly is a real help. That’s the best thing that has happened. And getting back to snorkelling and taking photos of the fish and urchins and everything. My ADHD brain does a bit better if I’ve got something to occupy me, rather than just floating around.
Clare: That’s just amazing. So, where can people find you, and do you have anything coming up that you would like to plug?
Meri: I’m @geek_manager on Twitter. The underscore is important because the poor lad who has got @geekmanager without the underscore sometimes gets questions that really, I am better suited to answer. He is very patient, bless him.
I suppose the main thing to mention is the wide variety of things that we have going on at Lead Dev. We are running Lead Dev Together at the moment, which is a multi-part series that folks attend with their entire team of leadership peers or tech lead peers or similar. I am excited, I’m running the last one of those, which is all about personal development and career coaching and that kind of stuff. Everything is on leaddev.com and it’s a great place to learn about technical leadership in general.
Clare: Fantastic. It’s been wonderful to speak to you, Meri, so nice to see you.
Meri: Always nice to see you, Clare.
Clare: Take care, enjoy the sea.
Meri: Thanks very much.
As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.
When dealing with legacy systems, architectural decision records or ADRs are a really powerful tool that help you get to the underlying why of the legacy system. I’ll remind you that most people come to work every day trying to do the best that they can. When changing legacy systems, think about what is the smallest thing that you can change and learn from, and try to avoid big bang cutovers.
Be wary of introducing major process change at the same time as major system change. Nobody ever designs a complex system from a blank sheet of paper that works immediately. What tends to work best is you get people to adapt their process in their current system, and once that works you add tech.
Service design is a great way of taking a step back and employing broader thinking. What are the real issues in your system? Frequent software releases significantly reduce risk. The more things you release simultaneously, the more bugs, the harder to track them down and the harder to fix them.
Blue/green deployment, canary deployment and A/B testing all help to ensure you are not changing everything for everybody or changing things in the middle of a journey.
If you are going to be able to successfully release frequently, you need to be able to run tests and have feedback faster that fetching a cup of coffee. You need good source version control, and you need good observability, logging, monitoring, and alerting, so that you can spot when things go wrong.
The change approval board or CAB checklist is the scar tissue of the organisation. Never forget that the code that is running is the code delivering value, and incentives for change approval boards aren’t necessarily the same as for developers. You can narrow the gap if you don’t separate Ops from Development. Be on call for when your own output goes wrong. Avoid silos, bring people together. There’s nothing more humbling than watching users use the thing that you’ve built.
That’s not all, stick around for some extra content.
Every other episode, this last, short segment will be devoted to Hack of the Month, where one of my colleagues, and in the future our listeners too, will share a life or a work hack. This episode, Hack of the Month comes from me.
This hack is clothes related. I’ve been doing this for twenty-one days now. I started it to relieve lockdown boredom, because I never knew what to wear. I mean, what difference did it make? All I was going to do was come up here and sit at my desk again! But I’m a bit of a hoarder and I own too many clothes, which feels like a waste because most of them just sit in cupboards and never get worn. So I decided to wear a different item of clothing every day until I’d worn every single item of clothing in my wardrobe. And I also decided to keep a record, by taking a photo every day on my phone.
But it’s become a fantastic database – I can now scroll through the photos in my phone. And by the time I’ve finished, I will have a record of every single item of clothing that I own. Not only will I be able to pick out what I want to wear each day, but it’s also going to be really useful at helping me to decide what to get rid of. I can see what suits me, what I like. I can see where the duplication is, and I’m going to be able to have a massive clear-out. I highly recommend it!
Working in the public sector means that at Made Tech, we really care about making a difference. So, for this final Making Life Better segment, myself and my colleagues will be sharing suggestions for small things we can do to make the world a better place.
This one comes from Adam Friday, who is one of our Delivery Managers here at Made Tech, and his recommendation to improve the quality of your life is to dance. He says, “Personally, I think music is food for the soul. It can really affect your mood, and helps with the isolation too. The dancing is optional, but I do like a boogie in the kitchen. I put some Jamiroquai on, and my legs flail independently of my body. It really helps my mood!”
And that’s the end of another episode. If you’re enjoying the podcast, please do leave us ratings and reviews because it pushes us up the directories and makes it easier for other people to find us.
Speaking of which, thank you to Maysa Kanoni, who’s recently left us a new review, and I can’t resist reading a little bit of it out. She says, “I especially enjoyed the story about the Chinese student, just wow.” That story is in Esther Derby’s episode, which is episode seven. We’d also like to thank Laurie32442 for their glowing review. I particularly like the fact that they say they’re now very unlikely to ever spell my name wrong!
I’ve got a few talks coming up. You can see the details on my events page on medium, which is linked to from my Twitter profile. And you can find that at @claresudbery, which is probably not spelled the way that you think. There’s no I in Clare and Sudbery is spelled E R Y at the end, the same as surgery or carvery.
You can find Made Tech on Twitter at M A D E T E C H. Do come and say hello. We’re very interested to hear your feedback and any suggestions you have for any content for future episodes, or just to come and have a chat.
Thank you to Rose, our editor, and to Richard Murray for the music. There’ll be a link in the description. Also in the description is a link for subscribing to our newsletter. We bring out new episodes every fortnight on Tuesday mornings.
Thank you for listening and goodbye.
[Recording Ends]Back to the episode