What A Lot Of Things: Tech talk from a human perspective

Get ready for a productivity party as Ian and Ash dive into the chaotic world of getting stuff done! From Ash's Trello-powered life management system to Ian's valiant attempts at David Allen's Getting Things Done, our dynamic duo explore the highs and lows of personal productivity.

Warning: may contain traces of work-in-progress limits and an unhealthy obsession with database administrators.

But wait, there's more! Brace yourself for a mind-bending journey into Conway's Law, where organizational charts meet software architecture in a cosmic dance of confusion. Watch Ian struggle to grasp Ash's examples (don't worry, he gets there eventually) as they unravel the mysteries of monoliths, microservices, and everything in between.

With a sprinkle of neoliths, megalithic humor, and a dash of LinkedIn bot paranoia, this episode is guaranteed to leave you questioning your team structure and reaching for your Trello board. Remember folks, in the world of What A Lot Of Things, everything changes while staying exactly the same!​​​​​​​​​​​​​​​​

Links
Email us on TechnologyEeyores@whatalotofthings.com or visit us on LinkedIn.

Creators & Guests

Host
Ash Winter
Tester and international speaker, loves to talk about testability. Along with a number of other community minded souls, one of the co-organisers of the Leeds Testing Atelier. Also co-author of the Team Guide to Software Testability.
Host
Ian Smith
Happiest when making stuff or making people laugh. Tech, and Design Thinking. Works as a fractional CTO, Innovation leader and occasionally an AI or web developer through my company, craftscale. I'm a FRSA.

What is What A Lot Of Things: Tech talk from a human perspective?

Ash and Ian talk about interesting Things from the tech industry that are on their minds.

Ash:

So in each in each thing in our notion database, we've added, a summary of our perspective. But I noticed that Ian has added 2 fields called Ian's perspective and only one field called Ash's perspective. Thus

Ian:

because I'm always in two minds about everything.

Ash:

So it's not nothing to do with the inherent unfairness of the What A Lot of Things podcast.

Ian:

No. There's no unfairness because we've defined fairness really clearly. And as long as we continue to take it in turns to go first, then we know that we have a perfectly fair podcast with no unfairness at all in any way ever anywhere.

Ash:

So you're not saying that your perspective has twice the weight of my perspective?

Ian:

Well, only if I write the same perspective in there twice, in which case you better bloody listen to it. Oh, so I'm gonna say that since my beating last time was definitely the second thing, I'm going to have the 3rd. No. Wait.

Ash:

Sorry. The beating was a little bit heavy, wasn't it? You've you've forgotten the way

Ian:

that it all works. I'm still a bit still a bit, dazed and confused as a as a consequence.

Ash:

I remember that.

Ian:

So I'm going to go first. Okay. So I have a thing.

Ash:

Tell us of your thing.

Ian:

So my thing is personal productivity. I'd like to say that was my thing in life, but feel like it isn't always. So I thought about this because I find this to be a continual battle. And I I don't know about you, but you see lots of people who sail through life in a kind of, look at me how productive I am. I wake up at 5 AM, and then every second is accounted for until I go to bed at 10 to 5.

Ash:

I take an

Ian:

ice bath. Morning.

Ash:

Yes. I bench press. It's £300. Yeah. I eat some kind of, seaweed breakfast or whatever it is.

Ian:

Yeah. Yeah. Yeah. Those people. So if you're one of those people

Ash:

Then look away now.

Ian:

Yeah. Yeah. We do include chapter markers in this, podcast so you can skip to the next thing if you don't want to hear yourself being pilloried. Yeah. So kudos to those people, but I am not those people.

Ian:

Okay. And I suppose the thing that that gets me is that there are some really interesting systems that people have come up with to help you be more personally productive.

Ash:

Okay.

Ian:

And I guess we should think about what does that mean. Sure. But I think it means I think there are some qualities of personal productiveness. I think one of them is this is the sort of stuff I should have written in the in the in the notes about this thing. So the first one is that you get things done that you intend to do.

Ian:

And another one is that you don't agree to do things for which you have no capacity. Yep. And it'd be nice if there was a third one I could think of. But

Ash:

So maybe if you worked on things that were of value, because that's kind of my perspective on personal productivity a lot of the time. Because it's all very well-being productive.

Ian:

But Well, yeah. Productive in the sense of getting things done. Yeah. But, actually, you want to get valuable things done.

Ash:

Yeah. The things that matter or the hard things or whatever it is.

Ian:

So the three things is turning into a bit of a Monty Python sketch now, isn't it? So that you get things done that you intend to do Yeah. That you don't agree to do things that you have no capacity for and that the things you do have value. Yeah. So if we say that's our that's the what a lot of things definition of personal productivity Yeah.

Ash:

I think until we talk about it more, I'm completely on board with that.

Ian:

And then we wind forward 10 episodes and release our own special stationery System. To system and and accompanying products to help you. You too can be as productive as we are. Although, I wouldn't say that was currently an aspiration that anyone should have Mhmm. About me anyway.

Ian:

But yeah. So if you adopt that kind of definition, then there's some, you know, very interesting systems and methods that people have come up with. Yep. And I think the most impactful one in in in this millennium

Ash:

right. Yeah. That actually, yeah. It's not been that long, is it?

Ian:

Is is David Allen's book Getting Things Done Yep. Which actually is charmingly pre digital in many ways. So in the book, if you read it, it talks about having folders for different days of the month and putting, and then folders for months of the year and then putting bits of paper in them that say when you're gonna do things. But, basically, this methodology that came up with for getting things done hinges on the idea that you have a system and that it is a trusted system. Yeah.

Ian:

What that means is every time you agree to do a new thing, it goes in the system.

Ash:

Okay.

Ian:

And my attempts at getting things done by his system always break down, and they break down when I'm really busy and have far too much to do. Yeah. And then I think to myself, oh, well, I can't I haven't got time to maintain the system at the moment. And then there's the first thing that you agree to do where you didn't put it in the system and you know it, it completely undermines the whole thing because it's no longer a trusted system, and you can no longer rely on it to have your entire spectrum of everything you've got to do in it. Yep.

Ian:

In which case, then you're just you've got a big load of things you're meant to do and some other things, and you're lost.

Ash:

Yep.

Ian:

So I suppose another maybe point 4 should be personal productivity has to continue to work in extraordinary circumstances and have too much to do.

Ash:

So you tried other people's systems?

Ian:

Yes. And, so I've got this really rather wonderful piece of software called OmniFocus

Ash:

Right.

Ian:

Which is only available to, those of us who are on Apple platforms. It's, comes from the Omni Group who've made some very good software, but only for Apple platforms.

Ash:

Alright. Omni Consumer Products. Omni

Ian:

OCP. That's what those initials already stand for Outside Context Problem.

Ash:

Alright. Okay.

Ian:

Which is, coined by Iain M Banks in his Culture series for when something happens for which there is no point of reference, which I suppose undermines their productivity.

Ash:

Because one of the things that I find really interesting is that people come up with personal productivity systems. And then I think that other people try and adopt them and they don't work because they're built for that person. It's like the Spotify model. Right? It's like maybe it worked for Spotify, but it won't work for anyone else because you're not Spotify.

Ian:

Yeah. But you see, that's are we all special and unique snowflakes?

Ash:

That's not quite what I'm saying. What you're gonna press upon?

Ian:

Is is it what you mean though? I know it wasn't what you said. Yeah. But it it's kind of suggesting that, actually, everyone has to have a their own unique solution. But, actually, it seems like a problem with a lot of commonalities between people.

Ash:

Sure. So to speak from my own personal productivity experience. So I have a I have a system. I haven't packaged it for sale to the world Yeah. Because it's just it's just a cobbled together system of things that I've collected over the years.

Ash:

So I have a Trello board, which has all of my life's tasks in it.

Ian:

Including this, this podcast?

Ash:

Including this podcast. There is actually a single task with multiple checklists called what a lot of things. Because if something repeats over and over again, I don't see the value in putting a I manage it by checklist rather than by task. Oh. And that works for me.

Ash:

I like that because it means that I'm not just creating 100 upon 100 of different tasks.

Ian:

So if you go to the ash system.com, you too can buy a screenshot of Ash's Trello board with all of the task names blurred out.

Ash:

So I have work in progress limits, which is the really scary part, which I think is the is the bit that a lot of people, organizations, however it however you want to phrase it, very rarely a tier 2.

Ian:

Well, it's the most counterintuitive thing in the whole of lean. Yeah. And trying to I mean, there's all these elaborate exercises on there for people to to try and

Ash:

Pushing pennies around and things.

Ian:

Yeah. Where where you're trying to illustrate to people the virtues of of only working on a limited number of things. The main one being that you finish them. Yeah. Yeah.

Ian:

Just even out of boredom.

Ash:

Yeah. So if I've got something, like, big going on in life so say I have a task called running. I run a lot. I run, like, 8 hours a week, which is a lot, which is like another day's work, basically. That always takes up one of my work in progress slots because it's a lot.

Ian:

So what is your WIP limit?

Ash:

4 tasks.

Ian:

And this is one of them?

Ash:

Yes. This might move in and out a little bit because it it ebbs and flows. So I'll come to that in a

Ian:

But consistency.

Ash:

Yeah. Well, it's ebbing at the moment. Now flowing rather than ebbing, isn't it? So Yes. It is.

Ash:

So let's let's just go with that.

Ian:

No. I've suddenly realized that, now there's this precarious nature of how how do we keep it in the, in the list of 4 things?

Ash:

So so

Ian:

Not a lot of things.

Ash:

So there are things that, like, become fixed, let's say Yeah. Like running. Or if I'm in a full time role, that will become one of the fixed things, and it takes up a spot in that work in progress. And then other things can, like, sort of flow past it or around it. But there's always I always have, like, a handle or try and have a handle on how much work in progress I've got.

Ian:

I mean, that's that's incredible, actually. I mean, I would love to do something like that, but I'd like that I don't think I could Yeah. It's It's difficult because you're always saying no to things.

Ash:

Yeah. So I'm not perfect by any means. I will often stumble over the same things and say yes to something that I shouldn't have done or start something which isn't in my I'd be like, oh, it'd be nice to write a blog about that. And I'd start writing it. And then after a little while, I'd be like, stop doing that.

Ash:

It's not in your add it to the board, add it to your list of blog ideas, and then you can prioritize it along with everything else because there's actually other stuff which might not be quite as exciting. Self assessment tax returns.

Ian:

Darling.

Ash:

Which are higher priority, and you need to do those first. And then you can have fun writing about testing and things like that. And it does take quite a lot of discipline. Yeah. And then I have epics and tasks.

Ash:

So I've taken bits from agile ways of working, taken bits from lean, work in progress limits, classes of service, and made them all into my weird system that helps me to get things done. And I think it's more like I've cobbled it together out of the things that I've learned into something that works for me. And if I wrote a book about it and other people might try it, but it might not work for them. So As long

Ian:

as they bought the book first. Yeah. Does that really matter to you?

Ash:

Yeah. That's true, actually. No. It doesn't. And then the layer underneath that is that for each event, say a conference or a task, say writing an article or whatever it is, I then create a folder on Google Drive, which is indexed by date to store all information pertaining to that event and or task matching and then put a link to that in the, in the Trello card so I know where to go to see all the notes and things that I've taken and all the documents and whatever it is.

Ash:

That is, like, the the, like, the layer the layer down of my of my system.

Ian:

So what's the smallest thing that can be a Trello card?

Ash:

So the smallest thing. Also, I need to book some travel accommodation for something me and Gwen are doing in London. That's a pretty small thing based on my board.

Ian:

And what's the biggest thing?

Ash:

So big things I've got in there are running Yep. Getting a new role because that was lots and lots of small tasks. But in my system, I decided not to create a separate one for each one and just had one task with a set of checklists in it to keep track of everything. And then what a lot of things, that's a big one as well. So at the moment, I have running the new role, what a lot of things, and I'm reading a book by Mark Winteringham on software testing regenerative AI, and that's in my doing.

Ash:

So my doing is full at the moment. So I will need to complete tasks of those complete the checklists on those tasks before I can move something else in.

Ian:

Do you complete them before they leave, or can you move them back in turn?

Ash:

You can move them back.

Ian:

Something really urgent came along. You could take one of those Yeah. Four things that's not one of the things to move move it move it back into.

Ash:

So I guess I'd probably make decisions like, say if someone said, you need to fill in this particular form for whatever tax or whatever it is. Yeah. I'd say, right, well, it's gonna take a while. I'd stick it on the board. I'd probably take something like the book that I'm reading out for now and focus on that.

Ian:

And you would then not read that book until it was back in again? Yeah. Well, it seems like a a very measured and sensible system.

Ash:

Yeah. I mean, it's completely I've it's grown over time. I've realized that some things just repeat. So, like, the what lot of things podcast, it repeats.

Ian:

Like a bad meal.

Ash:

So instead of managing it as a as individual tasks, it just made sense to to manage it differently. Yeah. Take away the admin and just have one template checklist for each.

Ian:

So what you might do is you might move it back into into to do Yeah. While you replace it with something else that might last 3 days. Yeah. And I might not even notice that you've done that.

Ash:

Yeah. Yeah. I mean, I don't like there's no estimates on any of these things.

Ian:

I thought I I can't believe that you have no estimates in your in your task with cash. It's just you you're just it's just such a departure from your normal way of working.

Ash:

Some some things have deadlines. So, like, for example

Ian:

The tax return.

Ash:

The tax return. I'm running a a race on Sunday, which despite my desire for no deadlines in my life at all, The world doesn't quite work that way. Certain things certain events will happen on certain dates whether you're ready or not.

Ian:

Yes. So That's an interesting one actually because David Allen talks about that.

Ash:

Alright. Okay.

Ian:

And he's and he's basically saying most things don't have deadlines. And he particularly rails against people who are or not people. He rails against the concept of adding a deadline to something just arbitrarily. I would like to do that by Friday. But is that really is that really a deadline?

Ian:

And a deadline is when you're committed to something or there's some unimmovable reason to do it. As you say, the race is on that day. Yeah. So You can have to do it then. So then not at all.

Ian:

But he's quite down on, I'm trying to think of the right word, kind of arbitrary deadlines. Yeah. People think, oh, I must put deadlines on all my tasks, but actually only on the ones that need it.

Ash:

Yeah. Yeah. So I think I subscribe to that. So, rather than just I know some people think or have the the belief that if you impose a short term deadline on something, it focuses the mind on achieving it. But I like to think, if something's important, I'll just go and do it, I think.

Ash:

I mean, I'm as vulnerable to procrastination as as anybody else, but I'm, if it's important, I think I'll just go and do it rather than waiting.

Ian:

No. That's I mean, that's again, is a very positive kind of approach Yeah. That I think I'd it's an interesting one. I I was read this, book by Oliver Burkeman, which is called something like might be 4000 weeks. Alright.

Ian:

Or I might have just made that up.

Ash:

It's not 10000 hours. That's something else, isn't it? So that's the practice one, isn't it? 10000 hours.

Ian:

Yeah. So that's the yes. You're right. 10000 hours is how long you allegedly have to do something for to become master it, which I believe has been a bit debunked.

Ash:

It's like doing 10000 steps a day. Right?

Ian:

Yeah. That's just a it's an arbitrary deadline. I mean, that's it's just an arbitrary number to give you a target to aim at. Yeah. It's not you know?

Ian:

But this his book is called 4000 weeks time management for mortals. Oh. And one of the fascinating things in that that he says is basically when you do something, everything you decide to do is accompanied by a million things that you decide to not do Yeah. At that time. And he's basically saying, any decision to do something is a decision to not do a load of other stuff.

Ian:

Yeah. And, actually, you can never do all the things. It's impossible. And if you try, you burn yourself out. Yeah.

Ian:

And what you've got to realize is you've got I mean, his 4000 weeks is about 80 years or something. So, you know, that's your time on the on the planet. And the way to approach it, he says, I hope I'm getting this right. There'll be a detailed apology in the show, but actually, he did a I met him because he did a talk at TEDx Manchester. Alright.

Ian:

Okay. Well, after he'd written this book where he kind of talked about it, so I met him briefly because I help out at that. But I think that you can't do everything. Nobody can, and you can spend your life feeling terrible with all the things you're not managing to do. Yeah.

Ian:

But I think he's largely he's basically saying what you've got to do is be able to fail gracefully all the things you don't manage to do. So rather than, promising to do everything and then letting everybody down Yeah. You just admit to yourself, I'm not gonna be able to do everything and and then go from there. Yeah. I thought that was actually that felt to me a bit more of a healthy perspective than the collect everything together and then do it all Yeah.

Ian:

Which was how I I came away from GTD.

Ash:

Yeah. Sure. Yeah. Yeah. I think you do need to have a healthy dose of of realism realism and forgive yourself your imperfections.

Ash:

So one thing I've noticed with my system is that if it doesn't make it onto the board, it doesn't get done, which

Ian:

Seems obvious. Yeah. It does. Probably not at the time of the decision.

Ash:

No. No. Absolutely. So and then I guess that's probably when it starts to lose its its integrity a little bit because there's probably something that's that's that's come in that I haven't put on the board and therefore I struggle to work on it because it's not on the board. But and then I need to stop myself and say right where does this fit?

Ash:

And so it's like having that discipline to do that. But there are sometimes, like, periods of, like, uncertainty where I'm like, oh, well, there's all these things coming from left, right, and center. What am I gonna do?

Ian:

So this is a bit tangential, but you know that Windows recall thing that was knocking around? So Microsoft, for their, copilot PCs, which are basically laptops with special extra AI processing power in them.

Ash:

Right. Okay.

Ian:

There was this thing called recall where basically Microsoft spy on everything you type, say, do

Ash:

Sounds good.

Ian:

On your computer, store it in a database on your PC, and then you can always go back and say remind me about x, and it will know because it's recorded everything going on in your computer. And lots of people have been very excited about that Right. In a kind of, you what? Kind of way. And some people and I think Microsoft have responded by encrypting the database on your local machine.

Ash:

Thank you.

Ian:

Thank you for that. If you had something that looked at everything you did on your computer, and maybe if it was an agent on your phone as well, it could follow you around and listen to what you were talking about and do all that. You could theoretically, even today, have an AI. This this is our productivity app, by the way. An AI that when it sees you doing something that's not on your list

Ash:

Tells you you're bad.

Ian:

Plays a siren. So it's like And you're like, oh, I now noticed that I was going to bed, and I hadn't written sleeping on my list. Just let me rearrange the the the trello accordingly. But, I mean, that's a bit frivolous. But you could imagine once AIs are able to look at all the stuff we're doing, that you could actually have an app that could help you stay on on track with that or at least make it more mindful.

Ash:

Yeah. I think, yeah, make it more mindful is probably the prompt you to

Ian:

Control all of your activities forever. Sorry.

Ash:

That's alright.

Ian:

I I pressed a button on my my machine to have said all of those things. Hang on. Hang on. I've got this.

Ash:

Squeaky voice.

Ian:

I will control all of your activities forever.

Ash:

That's better.

Ian:

But, yeah, making it more mindful and not reminding you when you're the I mean, I also go back to Dew, which is that app I we talked about last time where it nags you. Yeah. And, also, I discovered that was not for not for the Android and Windows people among us.

Ash:

Yeah. So the other thing that happens in my system as well, if if something is truly large, large but one off. For example, if I'm writing a training course or a tutorial for a conference, I'll put a placeholder on my life Trello board. It's actually called life. And with the link to another Trello board with the thing that is really large.

Ash:

Oh. So, like, the testability book, various training courses and tutorials, because I think that having them on this board would crowd it too much. Yeah. So there's a there's a placeholder with a link to another Trello board, which is which is temporary. And once I've done all the tasks and built whatever it is that I need to build, then it that that board would go away.

Ian:

Well, that's interesting because that again is about sizing, isn't it? Mhmm. It's it's keeping your life board at some way that you can visually

Ash:

Yeah. Because especially something like a training course or a tutorial, for example, because it's big and it has a deadline. So the conference is on this date. Yeah. So it's a large piece

Ian:

got to be ready.

Ash:

Yeah. Yeah. Exactly. So it's a large piece of work, and it has a deadline. So it comes back to those detecting what type of work that you're doing and responding accordingly.

Ash:

And that's what I do with things that are real big rather than trying to put them on this board. I will say, this is going to take up part of my work in progress. And then but the work the the individual tasks will be somewhere else.

Ian:

So what you're saying is that, basically, if I do this thing you're doing, I'll be fine.

Ash:

You might be. I guess that's that's

Ian:

It's not impossible.

Ash:

No. No. But you might think about work differently to me and think about, you know, productivity differently to me.

Ian:

I might be worse at saying no than you. Yeah.

Ash:

Maybe. Maybe. Because it is hard, isn't it? It's one of the it's one of the more difficult things that one has to do. Yeah.

Ash:

And especially when, say, if the work is someone says, can you come and speak at this conference? We'd really love to have you there. I'm like, oh, amazing. They really love to have you.

Ian:

Oh, this

Ash:

is incredible. I feel great.

Ian:

Oh, the dopamine. The dopamine.

Ash:

But then, also, there's a whole other set of things happening around that. Yeah. Then because a few years ago, I did have to drop out of a conference because I just had too many too much conferency sort of activity on. This was a few years ago now, and it was hard to to tell the organizers that I couldn't come and do it. Whereas now, I'm much more comfortable, because I have the system.

Ash:

I can look at it and say, well, actually, you've got a bunch of things happening in that month. So it's probably best that you say no graciously. Yeah. So, yeah, my productivity system and I think this is similar for everybody. It's it's just a set of things that you've learned over the years about how to manage manage your life.

Ian:

Or not.

Ash:

Or not. Yeah. Yeah. Absolutely. Absolutely.

Ash:

So I think that's the thing. It's like having a system is good, but then there's a whole bunch of experience which goes into managing it.

Ian:

Yeah. And you have to be able to trust it.

Ash:

Yeah. Yeah. I think the trusted point is a good one because I I trust my system.

Ian:

And that's because I think it's easier to trust the system where you can see all of it in one go.

Ash:

Yeah. Yeah.

Ian:

And that simplicity. Because the GTD system, especially in terms of OmniFocus, which has embodied it, there's a a concept of a context.

Ash:

Right.

Ian:

So what you what you're really trying to do is look at only things that you can actually do now. For example, if I'm at work, I can't do something at home if I'm at work, so I don't wanna see those tasks. And contexts can become arbitrarily complex because there's also things like, do I wanna do this really complicated and demanding thing in the art in the early afternoon? No. And there's a great book called, I think, When by Daniel Pink, which talks about time.

Ian:

It's all about time. Right. But one of the things it talks about is how everyone works in these cycles during the day, and, you know, there are people who are early birds or or larks as they call them, and there are other people who are like night owls. Mhmm. So it's not universal for everybody.

Ian:

Most people falling somewhere on a scale. But for most people, the early afternoon time is a very dangerous time to do something important. Yeah. And, there was a study done, he cites, in a hospital in Atlanta, Georgia, I think, where basically, if your operation was early in the afternoon, it was basically shockingly worse outcomes

Ash:

Right. Okay.

Ian:

For patients. Absolutely shockingly. Yeah. And they did a whole load of stuff to improve it. So they they made checklists, verbal checklists, where they have to verbally acknowledge to each other what they're doing and all this kind of stuff in in the OR, in the operating room because of how bad it is to do high quality work at the wrong time of day Sure.

Ian:

As for you as a as a person. Interestingly, it was kind of in the morning, your the word he uses is vigilant. Right. So you're able to do things requiring great amount of focus and attention to detail. And then in the early afternoon, it's just rubbish, and you should just do unimportant admin.

Ian:

Yeah. But then in the later on in the afternoon, you come back again, but you're much less vigilant, so you can do things involving creativity Yeah. Because your traffic your ideas traffic cop, if you like Yeah. That would tell you, no. Don't do that.

Ian:

It's people will laugh at you kind of thing. That is much more relaxed. Yeah. So you can you can be more creative later on in the day like that. I I it was a great book, actually.

Ian:

I recommend it. Yeah. So, again, what time of day? So you can in your GTD context, you can even have a kind of energy level

Ash:

context. Yeah.

Ian:

So you say I've got low energy levels. I only wanna see tasks that I can do with a low energy level. Yep. But what happens is as you implement all these different ideas, your system becomes arbitrarily complex, and harder and harder to maintain. Because every time you add a task to it, now you're thinking about where could I do that task?

Ian:

What how much energy do I need to do it? Yeah. It also has the idea of an inbox, by the way. So you collect tasks into your system with a very low friction way. So with omni focus, I can press, I mean, control space and type a task in and hit enter, and it's in the inbox.

Ian:

Yeah. And then you spend time organizing. So you look at your inbox and you say, okay. Where do these tasks belong? And if you're clever, then you're like, does this task belong, or should I be deleting it?

Ian:

All all these kinds of things. So there's a lot to like about that system, and I'm quite good at it quite a lot of the time. Yeah. I joke about it, but actually, I do you know, I get a lot of things done. Yeah.

Ian:

But am I good enough at saying no? Probably not. Am I able to keep track of it at times of high strain? And the answer is that is that's my Achilles heel Yeah. When I've agreed to do too much and I've got so much stuff to do, and I try to overcome my my desire to procrastinate because it's too stressful to look at

Ash:

it. Yeah. Yeah. Absolutely.

Ian:

You know, my mental health goes up and down like most people, I think. Yep. And sometimes can cope with climbing a a huge mountain, and sometimes I have to go and hide it behind a bush at the bottom, and I hope no one sees that I'm even in the vicinity of that that mountain. Yeah. I do get things done.

Ian:

Yeah. My Achilles' heel is, oh my goodness. I I can't possibly get all these things done. I'm just gonna start doing things and not use my system. Yeah.

Ian:

And it becomes untrusted then. Yeah. And that may be just because it's over complicated.

Ash:

Maybe. Maybe. But I think it's okay to be with your personal productivity. 1 must be gentle with oneself, and try and remember that. So even the people who say that they get up at 3 AM and, you know, have done 6 hours work before anyone else has gone out of bed, I would imagine they have their off days as well.

Ash:

And if they say that they don't, then

Ian:

I just think they must be perfect in every way.

Ash:

Well, yeah. Exactly. So I think

Ian:

We can't all be Tim Cook. Or Tim Apple as Donald Trump likes to be.

Ash:

Tim Apple. Well, it's an easier way to remember who he is. He probably does loads of Tim Cooks.

Ian:

Yeah. That must be it. Donald Trump and his vast array of Tim Cooks that he knows. He thought, I'll just call this one Tim Apple.

Ash:

Who's that text from? Tim Cook? I don't know. I've got 10 of those.

Ian:

So I'm exhaustedly emerging from the far side of that, I think. I don't know if we learned anything, did we? I I did. I think I learned about your very sensible sounding system. Well It seems to compare favorably to my slightly more free willing one.

Ash:

No. So I don't know. I just have my own system, but I recognize that the components of it are learned from lots of different places, and I've created something which works for me. I've never tried to take on someone else's system wholesale. So I don't know.

Ash:

It might work for me. It might not.

Ian:

Yeah. Well, I suspect when you're a productivity magnite with your system, the book of your system in the New York Times bestseller list, We will all

Ash:

Be more of a pamphlet.

Ian:

It'll be, I know. Well, just paste a pamphlet into an AI and ask it to elaborate on a little bit. That would definitely work.

Ash:

It's like put some treasure troves in there. Yes. Pad it

Ian:

out a bit.

Ash:

Pad it out a bit for me. There you go. Yes. Straight to the top of the bestseller shot. Yes.

Ash:

Yeah.

Ian:

Well, you heard it here first. Cool. Cool. I think it's time for an interlude.

Ash:

It is. It is.

Ian:

I'm just gonna sag back into my chair and reflect on my to do list. So you can just sing a song or drink a water. You drink drink your water. I do need

Ash:

a drink of water. So one thing I've enjoyed about the hunt for a new job has been the, the level of bots on LinkedIn who, as soon as you use the hashtag open to work, then they post and say, let's connect. But when you actually look at them, there's like, this is Amy Bradley with a picture of an elderly Chinese man, who is a homemaker who works for Nestle. And then

Ian:

That's a killer combination, isn't it?

Ash:

I was like, if you exist, then the world is not as I understand it, basically.

Ian:

That's a great phrasing, you know. If you exist, the world is not as I understand it. That should be your email signature or something like that. That just needs to be preserved Yeah. In some way.

Ash:

But then someone messaged me who does exist, probably, and said there's people asking you to connect with them based on your open to work post. So I was like, but they don't exist. But that's not the name of the game though, is it? No. The a the name of the game is to increase the follower count.

Ash:

So if you connect with people who don't exist, then you get an inflated follower count.

Ian:

You'd be better off joining Mastodon. I might have said that before. I can't remember.

Ash:

I don't know. I'm not familiar with Mastodon. So

Ian:

I'll send you a link, I'll send you a link.

Ash:

So that was that was one of my little,

Ian:

Achydurb. Io.

Ash:

One of my small amusements Yes. From the the recent job search. I enjoyed the, the bots on on LinkedIn, and they're seemingly unlikely combinations of names, pictures.

Ian:

I'm a percent s who percent s Yeah. At percent s.

Ash:

Yeah. Pretty much. So I did I did enjoy that. And then me misunderstanding those who wish to in inflate their follower account using utilizing these bots. I didn't follow any of these bots.

Ian:

No.

Ash:

No. So I'm not interested in inflating my follower count.

Ian:

There's a joke here about an inflatable follower count. Mhmm. Follower count, not follow account. I don't know where that came from. Well, I do.

Ash:

Yeah. But somehow these bots, they've managed to pass all the validations of being on LinkedIn. Right?

Ian:

All the validations.

Ash:

Whatever they are. It's a long time since I've registered for LinkedIn, to be fair, so I don't know what they are now.

Ian:

Yeah. Because I'm not gonna be doing it again.

Ash:

No. No.

Ian:

I already have slightly more LinkedIn than I can handle.

Ash:

Yeah. One of me on there is enough. Yeah.

Ian:

Yes. Maybe you should have another one called Northern Tester who can then post stuff about how he wishes he could be called Ash Winter, but but someone else has that name.

Ash:

No. Someone else might have Northern Tester by now.

Ian:

Probably. Although to be fair, with LinkedIn, you can have lots of people with the same name. Otherwise otherwise, it'll be a bit upsetting if you had a common name.

Ash:

Sorry. The other Ashwinters already got it. So are you ready for my my question thing, Ian?

Ian:

Yes. Go nuts.

Ash:

Go nuts. So is Conway's law dictating the systems that we build is my question. So I hear you ask, what is Conway's law?

Ian:

What is Conway's law, actually?

Ash:

So it was coined in the late 19 sixties.

Ian:

Was was it by somebody whose second name was Smith?

Ash:

Yes. No. It by Melvin Conway in the paper, how do committees invent, which I thought was a lovely name for a, a paper.

Ian:

You see, I would have thought it would be called how do committees prevent. Prevention. That seems to be what they actually do, but go on.

Ash:

So any organization that designs a system defined broadly will produce a design whose structure is a copy of the organization's communication structure.

Ian:

So for committees, we should read teams.

Ash:

Yes. I think so. In the in the modern parlance.

Ian:

In the modern parlance.

Ash:

Mhmm. But not that teams is a modern parlance as such, but such in in the way that we organize ourselves. Yeah. Yes. So it kind of posits another explanation, and the quote is, it is a consequence of the fact that 2 software modules, a and b, cannot interface correctly with each other unless the designer and implementer of a communicates with with the designer and implementer of b.

Ian:

Yes. Because a and b have to join together, so they have to agree and interface between them.

Ash:

Yep. So and then if your organization has the communication mechanisms in place for a and b to talk to each other and collaborate well, then they can do that. But if there's some kind of organizational barrier, departmental, whatever it is that stops them from collaborating and communicating, then it might be a more difficult task.

Ian:

But in terms of how it affects the structure of the thing being designed, the friction of communication is what defines a team, I suppose. So you have very good communication with people in your team Yep. And less good communication with people outside it.

Ash:

Yeah. Yeah. So I guess probably, like, examples are quite useful here. Right? Yeah.

Ash:

So for example, when I worked for a large credit reference organization in Leeds, there's only 1.

Ian:

So No one will ever be able to figure out who you're talking about.

Ash:

You know who you are. There was a very so there was a set of product development teams and then one very large database administrator type team.

Ian:

I thought So thought it was an individual. Just very large and muscle. Yeah. And Yeah. Nothing got past this person.

Ian:

People's lights out if they tried to change the database.

Ash:

So so the system was structured in a way that all of the product development team services all contacted one very large and one very centralized database

Ian:

Right.

Ash:

With multiple teams' data stored within it because you still had so in the development function, we'd broken off into lots of smaller development teams, but the responsibility for the database was still held centrally. So that remained as a central

Ian:

So this is like any centralized thing. It immediately becomes a bottleneck.

Ash:

Yeah. Yeah. Absolutely. Absolutely. So we that that's like one example.

Ian:

So but so so just let me dig into this Mhmm. Example. So Conway's Law is about how the architecture of, in this case, software Yep. Matches the team structure that delivers it.

Ash:

No. The organization structure.

Ian:

I think I mean might mean the same thing as that, or do I not I

Ash:

don't know. What do you mean by team structure?

Ian:

Well, I mean oh, sorry. I mean, the collection of teams that delivers it rather than the internal structure of any one team.

Ash:

Yes. That's that's how I understand.

Ian:

So there's the example is always compilers, which are things that, translate source code that programmers create into machine language that computers can execute. Compilers it was always said that, if you had 2 teams building your compiler, you would have a 2 stage compiler. Yeah.

Ash:

And I think it works on, like so say if you've got multiple teams working in different locations around the world on the same system, then you will start to get, like, a pull apart because of the lack of collaboration or easy collaboration between them. So there's a few different ways that it kinda manifests itself.

Ian:

So your database, I mean, that seems like, an example of a bottleneck. So talk a bit more about the structure of the organization and how that I guess I'm trying to understand how it illustrates Conway's law because I can't see it at the moment.

Ash:

So the organization structure was to have multiple product development teams and then one centralized database administrator team who did everything databasing. Yeah. So when we were building things and we wanted to change the database because of the way the organization was structured, we had to then request that from a central team to change a central thing. So we were doomed to repeat that pattern because of the way the organization was shaped.

Ian:

So the teams, I guess, were they responsible for delivering a different chunk of functionality or features?

Ash:

Yeah. Yeah. There were different systems, different services to do different jobs, which in theory, you would want to have their own database instance for the data that they needed to Yes. Yes. Yeah.

Ash:

But because of the way the organization was structured, as in the the large database admin team, they were like, no. No. That's too much trouble. We'll just have one instance, and everyone's data can go into it. And then we can control that, and we can administer it.

Ian:

Prevent all work.

Ash:

Yeah. Pretty much. Pretty much. But there was no organizational will to challenge that particular status quo. So the the structure of the organization remained the same and therefore dictated what we could build and how fast we could go.

Ian:

Okay. I'm good. I I I guess I'm I see that as an example of having bottlenecks and needing to design your organization to to not have bottlenecks, but this seems that the design of each is is not clear to me how it how it's driving the design of each system.

Ash:

I feel this is going terribly.

Ian:

Maybe it's just that example. Right. Shall we not do that example and do a different example?

Ash:

See, I think it's a good example.

Ian:

See, I don't I'd okay. So maybe maybe we are able to have an argument about this in the way that, we're supposed to. I see Conway's law Yeah. As driving the application architecture of a thing. Yeah.

Ian:

So if you're an ecommerce, you're doing a headless ecommerce site. You might have a checkout team. You might have a catalogue team or product catalogue team. You might have a payments team. You might have a search.

Ian:

I don't know. And if you do that, if you have those teams, it's likely that your application the boundaries that you that that you would have these boundaries in the application effectively, however many teams you had to do that, your application would basically have an at a high level, a component per team. Yep. And the the that would be cohesive and then loosely coupled to the things being delivered by the other teams in order for that to work. So you can look at the application architecture, and actually, if you draw lines around the different components that a team owns, you will see that the components owned by the team have more cohesion with each other and tighter coupling than as a whole, they do with the other team's components.

Ian:

And that's what I I see Conway's Law as being about. Right. So the design of the organisation, in other words, what teams you have and what their responsibilities are, driving the design of an application that they're all delivering together. Alright. And I don't I guess what my confusion is, I don't understand.

Ian:

I there's something very wrong with having a database, one database, and all these different teams Yeah. Having to put their data in it because it it it's it means that everyone becomes tightly coupled.

Ash:

Yeah. But that's how the organization is designed.

Ian:

You mean because we've got a database team?

Ash:

Yes. I agree with what you say. Okay. But I still think it's a good example because, essentially, you've got an organization which has been designed to have a centralized database administration team.

Ian:

Ends up with a centralized database.

Ash:

Yeah. Yeah. So so that ends up with the system with all all the data on 1 central in one centralized place.

Ian:

Okay. Now I understand your example now. I I latched on far too much to the disastrous dependency Yeah. Of why why would that and, of course, I'm thinking why would they do that? Because the answer is Conway's law.

Ash:

Yeah. Yeah. Exactly. Because, you know, in the in the past, it's always been better to have a centralized database administration team. And then there was other reasons as well.

Ash:

So these these database administrators, they were the ones who were on call to fix things. Yeah. So they wanted the world to be less complex, one place to go to look at things.

Ian:

I want the world to be less complex.

Ash:

Exactly. We all do, don't we? So that's what they desired. So there was no desire to change the organization structure. Because if the organization structure became a bit, like, a bit looser and maybe you had a, I don't know, smaller database administrator teams or even a database administrator on each team, then you might end up naturally pulling apart that system.

Ash:

But the com the communication structure as it was dictated that the system would be centralized, the database part of it anyway. And I agree. It's a it's a crazy example of something you should never do. Yes. But, you know, that was the situation at the time.

Ian:

That's interesting. I mean, were you sort of did you have a sense of the history of why was it just that there's always been a central database on

Ash:

the streaming team? Just organizational inertia.

Ian:

So somebody said, right, we're gonna build the first of these systems. And they said, well, you're gonna have to store the data in the in the central database or by the central database administration team. Yeah. Okay. Well, maybe I'm just being done before.

Ash:

Well, I think you would if you come out from an idea of, oh, why have they done it like that?

Ian:

Yeah. Yeah.

Ash:

Then I see where

Ian:

you're coming from. It's a very attractive, piece of bait there too.

Ash:

Yeah. But, you know, silly things happen within organizations just because of the way, again, they're they're structured, and that's it dictates what gets built.

Ian:

It makes perfect sense if the database team was there first because of Yeah. The historic databases that Yeah.

Ash:

Sure.

Ian:

The company had had. Yeah. Yeah. Hopefully, the dumbest bits can be cut out during editing. Well Ian's tone of incomprehension.

Ash:

I mean, it's hard to give like, I I wanted to give an example of, like, me seeing it Yeah. Yeah. Rather than a generic example of, you know, you have these different pieces. Yeah.

Ian:

Ex Exactly. Traditional generic example.

Ash:

I mean, yeah, I mean, it's a fair one. But

Ian:

Yes. So

Ash:

yeah. So, where was I? So we talked about briefly before about the mythical man month.

Ian:

Fred Brooks?

Ash:

Fred Brooks, which is a collection of essays by Fred Brooks. My favorite one of which is, the programmer would have a team of administrators and secretaries and things like that around them, which always made me laugh. So

Ian:

Back in 19 whatevers.

Ash:

Yeah. Yeah. So it was Fred Brooks who first coined the term Conway's law, and he and he said because the design that occurs first is almost never the best possible. The prevailing system concept might may need to change. Therefore, flexibility of organization is important to effective design.

Ash:

And

Ian:

almost anathema to people who have to manage budgets and Yeah. Other such

Ash:

Yeah. Absolutely. You say

Ian:

can organization things.

Ash:

Yeah. And I think that's one of the one of the key points, isn't it? That I've always found that convincing a bunch of developers and testers and other roles around software development to do things in an iterative, emergent fashion is not too hard, but convincing the rest of the business when they ask you for a budget forecast for the next 5 years

Ian:

Yes.

Ash:

Is much more difficult, which and, again but that speaks to to Conway's law because, say, if, you know, you all asked for how much money you're gonna spend in the next 5 years, then you might over egg it a little bit. No.

Ian:

Nobody's ever done that. That's that's just so terrible. Everybody will try and come up with the leanest possible budget because they know exactly what they're gonna have to do, and they can exactly estimate how much it'll cost.

Ash:

And you might commit to bigger things as well than you might necessarily do so. So your systems might suffer with bigness as well, as in, over engineering and over over scaling and over whatever

Ian:

it is. It's just just completely impossible. I don't understand. You know, you're just trying to convince me of something that will never happen.

Ash:

And then the other thing that I found quite interesting was the inverse Conway maneuver Oh. Which sounds amazing, doesn't it? Yes. So you change the communication patterns, of the designers to encourage the desired software architecture.

Ian:

So, basically, the architects should be in charge of the organization? Yeah.

Ash:

Pretty much. Yeah. You should bring them all in from IBM and put them in charge of everything.

Ian:

That will never happen.

Ash:

So I guess, say if you've got a whatever the current phrase is, let's call it a monolith, a monolithic software product, and you want to break that up.

Ian:

Into microservices.

Ash:

Into might something more micro. Yes. Indeed. So you might say, okay. Well, let's take a bunch of teams all working on the same code base and split them up.

Ash:

And, eventually, they will start to pull apart and decompose themselves. And that's that's what the theory is. So there was one particular place where I worked where there was 10 teams working on the same code base, And, I'm not sure who started to pull apart, to be honest, while we did it. Everything was very tightly coupled, and most changes had to be very, very closely managed.

Ian:

Was there a change management board?

Ash:

No. But we tried to cope with it by doing smaller and smaller changes.

Ian:

Oh, that's no bad approach.

Ash:

Yeah. But it was a coping thing rather than a fixing thing. Yeah. So I'm not sure that the inverse Conway maneuver, from my personal experience anyway, is particularly effective.

Ian:

But But it's a great name,

Ash:

so these are all adopted. It is a great name. It is a great name. That's always one that I try and treat with a little bit of what's the word?

Ian:

A pinch of salt. Yeah. With a bit of caution. Loads of salt. Loads

Ash:

of salt. I salt it. Yeah. I salt it thoroughly.

Ian:

Yes. Make sure it can never grow again. One thing that we've talked about a few times, in fact, it's even been a thing, is team topologies. Yep. Where you're kind of designing you've got teams that are delivering parts of your system.

Ian:

Yep. And then you may have a platform team that's basically helping the teams to go faster. So is that somehow doing a bit of a sneaky slide past Conway's law, or is it simply that the non platform teams, the feature teams, or whatever, the architecture is matching what they're doing, although they're able to go faster?

Ash:

Yeah. Because the idea is that you would, through some form of mapping exercise, you would find out what your what your value streams are. Yes. So which is, like, how you might break down the work that's already being done, but organize it better into things that deliver value in there.

Ian:

We are gonna have to have worldly maps as a thing. It's the one I believe.

Ash:

Yeah. Yeah. Absolutely. Yeah. Yeah.

Ash:

And then you would then, like I said, have, like, a a platform type team to help those teams to deliver the things that the feature team has to deliver the value that exists within their streams.

Ian:

I mean, does team topologies take account of Conway's Law?

Ash:

Yeah. I think it's definitely an inspiration. It's in there. It's in the book. Yeah.

Ash:

Because I think it does make you, I think it's it's one of those concepts that makes you aware of what's happening in your organization, gives you a bit of a a higher level view. So you're like, why can't those teams talk to each other, and why do they keep having problems with their contract between each other? What is going on there? And it might be because there's some kind of invisible or more visible organizational barrier. You know?

Ash:

There's or they don't own something that they need to own or whatever it is. So I think team topologies is inspired by that kind of thinking.

Ian:

And I guess you have to be therefore flexible. Yeah. Yeah. As your software architecture evolves Yeah. That you you change your teams to match.

Ash:

Yeah. Yeah. So rather than just wishing that the world would be the same, because that's, I guess, that's another team topologies thing where it's like you as you evolve the product, your value streams will probably change. So you need to go through the exercise regularly to detect what those changes are and to organize your your teams accordingly. Because there are alright.

Ash:

I had a point then, but it's gone.

Ian:

You're now pointless.

Ash:

I am now pointless. No. So I guess let's start from a new question. Sorry. I'm getting tired.

Ash:

There's been a load of new practices, technologies, microservices, cloud, which

Ian:

Since Conway.

Ash:

Since Conway. Yeah. Since the sixties.

Ian:

Post Conway and pre Conway. That's how we can define the world.

Ash:

So I I was wondering, I'm gonna put in one of the questions in the notes. Have the rise of these different techniques for building software and the cloud? Have they mitigated this? The effect of Conway's Law Laurel. So it's easier, I think, for teams to take control of their their dependencies and have their own environments and build smaller things.

Ash:

So I I don't know. Part of me thinks that maybe this effect has been mitigated a little.

Ian:

Well, perhaps these things are molding themselves around that. Yeah. I mean, cloud is basically enables you to to do things quickly that used to take a long time. Yeah. And then because people can do more things, you can perhaps have smaller teams that then deliver.

Ian:

Yeah. I mean, microservices is great from that point of view, you know, once you've got to a certain size. The thing is that, actually, Conway's Law probably lies behind this whole monoliths microservices thing. Yeah. Yeah.

Ian:

Yeah. Because a start up is a small team. It has one team. It builds a monolith Yeah. Because it's just one of it.

Ian:

Yeah. And then when it's successful and is, you know, making in the the tens of 1,000,000 or whatever, and they've got 50 teams, the only way to really for that to work at all is for them to own their own microservices and work on them. That's interesting. I had not thought of that at all before because, of course, you've read the DevOps handbook and you you the stories of Amazon and LinkedIn, all these big companies that went through a a transformation from a monolith to microservices basically as a kind of existential crisis at some stage in their growth. And I guess what actually lies behind that is Conway's law, isn't it?

Ian:

The stage in their growth meant they'd hired all these people, and then they divided them into teams because you can't have a team of 300 people because it's just nuts. So they divided them into teams, but the teams are all tightly coupled because they're working inside a monolith.

Ash:

Yeah.

Ian:

And so that's why that's where the existential crisis comes from, isn't it?

Ash:

Yeah. So you you're then compelled in order to grow further to break it all down somehow, some way, and you'd choose a pattern that that helps you to do that.

Ian:

And then, Martin Fowler's strangler vine.

Ash:

Oh, yeah. Yeah. The, yeah, yeah, the strangler pattern. Where were

Ian:

He's apparently, re written a blog post more recently updating that.

Ash:

Yes. I think that's not a nice phrase, is it? Well, it's definitely isn't a nice phrase.

Ian:

No. I'm not sure. I haven't read the blog post. I've just seen that it's the rest. Okay.

Ian:

Yeah. I wonder if it if it does do that, if it re re recasts the terminology. But that that is interesting. I haven't thought of that before. Yeah.

Ian:

But, actually, you can see why small team makes a monolith, and then growth forces you to break into microservices. And, actually, it might explain that microservices is not a good way to go to begin with. Yeah. Yeah. Because you're kind of trying to forestall Conway's law even though you're not multiple teams.

Ian:

Yeah. And you may be trying to it's like, I'm just trying to defy gravity by meditating really hard or something. That might be a bit of a frivolous way of putting it, but you know what I mean.

Ash:

Yeah. And I often think about the size of teams as well. So I I I guess I come at this from a tester's point of view. So if I see a team with that says it's a scrum team of, you know, 7 plus or minus 2 people, it's always plus 2 people generally. Let's get this straight.

Ash:

Yeah. Yeah. And then you've got, like, 8 8 developers to a tester or whatever. And I'm like, is this part of maybe it's not directly, but Conway's Law related. But it's like, if that is your vision of a team, if that's the composition, then you're dictating your system as well, aren't you?

Ash:

Or or at least it's bigness.

Ian:

Well, you're you've got an interesting thing there, haven't you? Because as you take on more people, if you add them to an existing team, that means that you cannot have to change your Conway's law inspired monolith to a dualith or or something. Megalith. Megalith.

Ash:

I think megalith is actually a phrase, isn't it?

Ian:

It is. Yes. I think it's like standing stones or something. I think such Stonehenge has megaliths.

Ash:

You're a neolith. Megalith.

Ian:

That's where, somebody's added an extra stone to Stonehenge in modern times. That's a neolith. Oh my goodness. Let's make up a few more words, and then we can but neologisms. Yeah.

Ian:

Oh, we're so funny. But, yeah, that how do you add people? So you're a startup. How do you add people to your team that's working on your monolith? And it's much easier to add them probably possibly unwisely to an existing team.

Ian:

Yeah. Because if you make a new team, what's it gonna do? What will it be responsible for? What's it gonna own? How are you gonna make it loosely coupled compared with your current team?

Ian:

Yeah. But the amount of work you need to do, it keeps going up and up and up, so you need these people. So you you can start to see that managers looking at this problem have not got any attractive options. There's some point where you need 2 teams. Mhmm.

Ian:

But actually, your application matches the one team.

Ash:

Yeah.

Ian:

Or maybe you've got 3 teams, and the amount of progress you need to make goes up and up. You recruit people. Do you make a 4th team? And if so, how do you how do you find something for it to do that's not tightly coupled to what the other 3 teams exist or working on?

Ash:

Yeah. Because, you know, it depends on the balance of work, doesn't it? Yeah. Some of it might be new functionality. Some of it might be changes to existing functionality.

Ash:

So how do you then how do you then dole out through teams?

Ian:

Well, maybe you just say, well, we're gonna make a platform team with all these new people. Yeah. And they can just make the first three Yeah. Teams go faster.

Ash:

Yeah. I once worked on a team of 30 people.

Ian:

That's not a team.

Ash:

It's a gang.

Ian:

That's a loose confederation of raw individuals.

Ash:

And the the strange thing to me was it obviously needed to split. And every day, we said we need to split the team somehow. But yet, the no one wanted to do it.

Ian:

But is that because no one could think of Yeah. That it's the the architecture. You're the team of 30 is working on something

Ash:

Yep.

Ian:

That is hard to envision how it that can be split so the 2 teams can work on 2 parts of it.

Ash:

Yep. So, yeah, the the team of 30 were working on one one one monolith, if you like. Mhmm. One large code base. And it was just very difficult to say, well, who does what, and how do we not trample all over each other without directly speaking to each other, in the same team.

Ian:

But but the good news about this is that while it feels imponderable in the situation, there are actually all these patterns that you could look at Yeah. Yeah. For how to do that. And the obvious one is take a little part of it out, make it a new thing. Yeah.

Ian:

Yeah. But these patterns, well, there's loads of them, and they're all documented very well. I feel a lot smarter in this bit bit of the discussion. So thank you for that thing. Okay.

Ian:

And, I hope we can edit out the bit at the beginning where I was stupid.

Ash:

No. Let's keep that in.

Ian:

No. No. No. I think we'll be editing that out because we're at a and at we're at 89 minutes exactly, which will be an editing extravaganza. Yes.

Ian:

So that convenient whole section could be just chopped out, and I can appear not to be not to be dumb. I only appear, but I will probably remain at the same level of intelligence that I currently am at. But, yeah, that was a very thought provoking thing. And, actually, when you start looking into it, how deep it runs through everything.

Ash:

Yeah. Yeah. And it's one of those interesting noted many, many years ago, but still very, very relevant Yes. Today. Yes.

Ash:

So it's it's always worth keeping these these older parts of wisdom in mind when you're looking at your organization.

Ian:

Yes. In in technology, everything changes at the same time as it all remains the same.

Ash:

Yeah. Exactly. Cool. So that was my thing.

Ian:

Thank you, Ash. That was an outstanding thing. Outstanding. Remarkable. Remarkable.

Ian:

Top of the range thing. Monumental. Monumental. Yes. Megalithic.

Ash:

So how do you get in touch here? Have we done that?

Ian:

Well, I'd like to say that you can tweet to us at what a lot of thing.

Ash:

But you can't.

Ian:

But you can't because while you could do that we probably wouldn't notice. But you can get in touch with us via email. Yep. And, rather than having a nice simple version of the email address we're still going by technology Eeyores at what a lot of things dot com Okay. Which we will write in the show notes because we expect that people can't spell that.

Ian:

How else can people get in touch with us?

Ash:

The LinkedIn group as well?

Ian:

The LinkedIn group. Yes. If you are swimming round in the healthy, clear waters of LinkedIn that's not at all accessible Bots. Commercial, avarice, and bots, then join our LinkedIn group because there are no bots there. Just the cream of the LinkedIn crop.

Ash:

Yep. And I've been sneakily inviting people to follow the group

Ian:

You have.

Ash:

In small batches.

Ian:

And some have been doing it.

Ash:

And some of them have indeed been doing it.

Ian:

So And we like doing things in small batches, don't we? Small batch size is very important to everything we stand for.

Ash:

Everything. Apart from the length of the podcast.

Ian:

Apart from the length of the podcast as we hit the 92 and a half minute mark.

Ash:

There you go.

Ian:

But that's fine because by the time we've edited it, it will doubtless be about 12 minutes, and you'll be like, that was that's too small. Do you, please?

Ash:

Give it a moment.

Ian:

Have a bit more.

Ash:

So I guess all that's left to say is thank you very much.

Ian:

You're welcome. Oh, you mean?

Ash:

I mean everyone who is involved in the podcast.

Ian:

You, me. And you who's listening.

Ash:

And you who's listening.

Ian:

Particularly, perhaps I'm a bit hungry.

Ash:

He needs a snack.

Ian:

He needs a snack. He always needs a snack. Thank you for listening. We love this time this time that we spend with you every 2 weeks.

Ash:

Press the button.

Ian:

Press the button.

Ash:

The other button. Press the button that stops the recording.