Late vs Early
Chris, Peter and Fraser talk about being late and being early. Which is worse?
For more information on Aleph Insights visit our website https://alephinsights.com or to get in touch about our podcast email podcast@alephinsights.com
Transcript
Hello and welcome to the Cognitive Engineering Podcast produced by TellMeStudios for Aleph Insights. In this series of podcasts we take a look at interesting topics and discuss what we think they tell us about analysis and decision making. I'm Fraser McGruer and I'm here with Peter Coghill and Chris Wragg of Aleph Insights and this week Chris is going to be telling us about a late running train journey of his. Okay, Chris, tell us about your late running train.
Speaker B:Well, so this is a train that I get to actually come and record these podcasts, so I regularly get this particular train at a particular time and it's occasionally late, but in this particular instance there was a cow on the line, so the train had to slow in order not to run over the cow and that was occurring early on in the journey, in the sort of rural part of the journey, but then subsequently there were then signalling problems when we started coming into London which further delayed the journey and then congestion related to actually having to get a platform at Waterloo Station which further delayed the journey again and it got me thinking about why it is certainly that our perception seems to be that when a train journey starts to become late it only ever gets later after that, it's not that you then subsequently regain time somehow and end up being closer to being on time than would otherwise have been the case, it always seems to just get later, so it got me started, or it started me thinking about why it seems to be easier for a train to be late than it is to sort
Speaker A:of be early. Okay, I think there's another angle here as well which we're not going to go into today which is what's going on with these cows and fencing and adequacy of fencing and so on
Speaker C:and yeah, a rurally aimed podcast, yeah, the quality of fencing in the British Isles today, yes, and
Speaker A:church bells being too loud or something. Okay, Peter, do you want to sort of take us on from
Speaker C:there? Yeah, well, the train system, like many other things, is engineered, you know, it's been built and designed by people and one of the ways that you can save costs is by ensuring that it runs as a just-in-time system, meaning that you don't have lots of spare rolling stock hanging around because it costs you money if you're renting the train or it costs you money to maintain and run a train, so if you have lots of rolling stock knocking around, that's a cost, so you're trying to minimise that as much as possible, so at every point of the system is vulnerable to failure because it doesn't take much to upset a fine balance of being just-in-time, so take, for example, your train timetable is partly dictated by fundamentals, so distance between stops and the speed the train can travel, so there's lots and lots of sort of fundamentals in this equation and it's a big complex planning problem, but they can't account for everything, so cows on the line is a good example, they have an assumption that the fences on the side of the train tracks are good and cow-proof, but that can change and can't be planned for, so a small little change like a cow appearing can seriously upset this balance.
Speaker A:So it's the case that the system is built so that actually it's kind of almost at capacity, I don't know if that's quite the right term, but if things are going to go wrong, they're only going to go wrong in one, if things are going to go off time, they can only go off time in a bad way, not a good way, and actually you could have a system where actually it would be easy to make up time, but that would probably be a quite costly system to have in place.
Speaker C:Exactly, it's an engineering choice to have spare capacity in the system, so something you could do is incur greater costs and allow the trains more leeway, so if they leave a station a few minutes late, they can throttle up to get to the next station on time, and they do that, they have speed limits that they have to adhere to, but there is a little bit of slack in the system, so they can try to make up time. But, when you get a cow on the line compounded with a signal failure, you've not only got lots of factors which you're not planning for, like cows on lines, but you've also got factors which you are planning for, like a certain rate of signal failure, however, there's not only things you haven't thought of, there's lots of combinations of things which you haven't thought of, which can suddenly upset things, so in this example, it's sort of a multistage system. There's a multitude of errors which have caused the system to break down. However, I think what's amazing though, is how resilient the system actually is, because Chris still arrived, and not hugely, I mean, how late were you? I was about 45 minutes late. Out of what was your overall journey time? Two hours, so it was a sizeable increase. So nearly 50% extra time spent travelling, but you still got there, right? You weren't forced to abandon your journey.
Speaker B:That's right, and I think there's a couple of interesting things, while I was delayed for 45 minutes, that I was contemplating, one of which was, I think there's a general perception about lateness and trains that people have, which gives evidence to the existence of the availability heuristic. I think generally when studies have looked at people's perception of train lateness, people overestimate the amount of times they are late on trains, because they remember them more clearly. So I first of all had to question, is it true that once a train starts becoming late, it only gets later, or do I simply remember those events where I've been on a train that has been at least 45 minutes late, and they stick in my mind and become, they seem like the frequency of them is greater than they actually are. So there's that issue, and the research that's been done does show that people over-remember late trains.
Speaker A:Okay, so there's a question of perception here, but also there's a question of what is the main aim of the train, and it is to get you from point A to B, and probably, actually, although we're sort of slightly fixated on timing, as Peter has said, actually the system is designed as such, so that actually if something's going to give, it's going to be the time, and it's going to be late. However, there are certain other things, and probably the main aim, actually, we'd probably all agree on is that we want to arrive safely, and I'm guessing that pretty much 100% of us here have never been involved in a major train accident, anything like that, and so actually from all our train journeys of thousands of hours probably combined between us, we've always arrived safely. So actually, yes, we're fixated on one thing, but maybe the most important thing.
Speaker C:I don't know what the stats are, but I think train journey, train is by far the safest mode of transport when compared to, it's probably comparable to air travel, but vastly safer than travelling by car.
Speaker B:But I think the thing that it highlights to me is that these kinds of complex systems, it definitely seems to be the case, and in fact the metrics that train companies have to sort of aim for, I think even reinforce this, that once something drops through the cracks, it's much more, it gets kind of written off effectively. So a really late train is better by the metrics they are measured by than 10 trains which are a little bit late, and so there seems to be a sort of systemic kind of approach to the way these systems are constructed. That when something drops through the cracks, when you get these compound errors, it's easier to let those go than it is to sort of inconvenience lots of passengers a little bit.
Speaker A:Yeah, which has a very real effect for trains because they've got certain targets and financial penalties, etc.
Speaker C:That's a good point. I think when they're calculating the lateness of a particular train provider, they do account for every minute of every train that's late. However, what is much harder to calculate is the sort of overall level of inconvenience to your passengers. It might be that there's a particular train journey that lots of people take that's only ever a minute late, but it's very consistently a minute late, but that minute causes them to then miss a connection, which causes them huge amounts of cost.
Speaker A:I want to broaden this out a bit, but before we do that, something I want to pick up on is that as we record this is in a beautiful English summer's day, one of the hottest days of the year, and Peter was complaining about being hot, but Peter, you're doing something which I just don't understand why you're doing it on a hot day like this. You're wearing socks as we record this, as is Chris. Now, Chris is okay because he's not complaining about being hot and probably isn't hot, but look at me. I've got my bare feet here as we record.
Speaker C:You've got a scabby bandage on one foot, but we won't ask about that. I just haven't taken them off because I cycled here today, and that was a heat avoidance strategy because I wanted to, at all costs, avoid the Northern Line because it's just horrendous on days like this. It's horrible and hot during the winter, let alone on a day like this. They're my cycling socks, and I've just not taken them off.
Speaker A:But hold on, I cycle a lot, and I often, in fact, I was cycling just yesterday, and I was cycling barefoot. I'll take them off if it makes you feel better. Well, no, it's about what makes you feel better. It's just your welfare that I'm concerned with here.
Speaker C:Well, I don't much like the look of my feet, but I'll take them off for Fraser's benefit. Thank you. He obviously likes my ankles.
Speaker A:I do find, though, when it gets to the end of the summer, autumn time, if I've got to have a formal meeting somewhere and I have to struggle putting on socks and shoes, one, I really don't... Do you need someone to tie your laces? Well, I've had to just go to Velcro these days. I just can't handle it.
Speaker C:Have you got a stick with a claw on the end for doing the Velcro up and bend down?
Speaker A:But one thing I noticed is how the state of my feet at the end of the summer, because they do get all kind of ingrained dirt and quite calloused and so on, but it's because my feet are free, so... Let them breathe. Yeah, let them breathe. Anyway... Hashtag free the feet, sponsored by Tell Me Studios.
Speaker B:Fraser and Peter's feet aside...
Speaker A:So broadening this out, we've been talking about trains, but I think there's a general thing. What is it called? A planning fallacy? You guys know more about this than me. Hofstadter's law. This thing about generally how we underestimate a task, and it's so much easier, and I do this all the time, is I estimate a certain... For example, editing these podcasts, I think, oh, yeah, I'll sort of do that in half a day or something. And it ends up taking me all day, but that happens every single month or every single week when I do these. So what's going on there?
Speaker B:Yeah, so I think Hofstadter's law is... Well, it was developed in relation to computer science and the length of time it would take to solve computer science problems like developing a chess machine that can beat a grandmaster or something along those lines. But it essentially says that things will always take longer than you think, even when you take into account that things will take longer than you think. And that that is just effectively a feature of, I suppose, a little bit of optimism bias that gets us to start attempting to do a task in the first place that otherwise we might not. But also is a feature of complex systems, and as we get more and more into a problem, we understand how complex they are.
Speaker C:Yeah, so when you're forming your plan to build something or deliver something or design a train system, if you're starting from scratch, which most people are with a lot of problems, you have some idea of the things that could go wrong, and you've got some ideas of how you might fix them. But as you get into it, you start finding more things that are going wrong, and you might find that your mitigation strategies aren't quite as simple as you first thought. So you have a sort of... There's an optimism in that you think you're good and you can nail it, but there's also an optimism in that you're underestimating the complexity and the difficulty of the task.
Speaker B:I think this relates to the sort of idea of entropy as well, that entropy and chaos within a system only ever seems to move in one direction. It only increases. I mean, Peter is an engineer, he can tell us a bit more about thermodynamics.
Speaker C:There's a tendency of things to move to greater disorder. So if the universe is left unchecked, it becomes less ordered as the energy is redistributed. When you're building something or planning something, what you're essentially doing is creating a local pocket of low entropy. So you're putting work in to make things more ordered. And so you're kind of fighting against the universe in that respect. The universe just wants to make things a mess. Whereas you're trying to impose order and legibility on a particular part of the universe to be able to predict when trains are and be able to deliver a piece of software or whatever.
Speaker B:Yeah. And I think this is an important sort of analytical lesson in terms of that, trying to establish order and dealing with compounding risks like a train getting later or things such as the Fukushima nuclear power plant disaster, which was one of these kind of cascading risks where a series of events, an earthquake followed by a tsunami, followed by a tsunami. Followed by a, you know, a meltdown at a power station, a series of events cascaded and caused something. And as planners, and when doing the analysis to do planning, there's a real sort of onus on us to build in kind of firebreaks that prevent things from getting more and more full of, you know, greater and greater disorder. So that at some point, the disorder ceases, it hits a fire break, and you can get back to the nice order that humans like. And it's, that poses an interesting analytical challenge.
Speaker A:What about in, you know, I know, we're talking about planning sort of grand projects and stuff. I just can't help but think back to myself and editing these podcasts, how it always takes longer than I expect it to do. So that's just me fighting against the chaos of the universe. But it does feel like that. And your mind. And the chaos of my mind. But is it just me? And I'm just not learning from this stuff. And I mean, that's actually a relatively simple problem. And it's the same problem again and again. And yet I still always...
Speaker C:Yeah, well, I think probably what you don't do, and knowing you reasonably well, I think you definitely don't do this. But you probably don't keep a record of how... So the podcast editing task is fairly similar month to month. So you probably don't keep a record of how long you actually spent doing it in the past. So you don't have a diary of when you've done a task, how long it took you. If you did, then you would have a very good set of data for working out how likely the next one is going to take. So if it always takes you an hour, and you've done 8, 10 editing sessions, the next one's probably going to take about an hour. But when you're planning your task, you probably haven't taken into account all that data that you've got. And you're probably just sort of saying, well, you know, similar, other similar things, but I reckon about half a day.
Speaker B:I think there's also an element of people tend to plan in chunks. So they think, right, I'm planning, that thing takes me three minutes, that thing takes me five minutes, that thing takes me two minutes, therefore, this thing will take me 10 minutes. And there's an element of the sort of conjunction fallacy in there, which is that you sort of assume the best case scenario for each individual component and think, yes, I usually get each of those bits about on time. Forgetting that across the three different elements, or the multiple elements, one of them is pretty likely to go wrong and cause you a problem. In fact, you know, often two of them all go wrong, and may well compound one another, you know, you get, you take longer on one phase of it. And that then means that the product that comes out the end of it is a bit more disordered and needs a bit more sorting at the end of that.
Speaker A:Well, I mean, apart from being highly affronted by the suggestion of my less than optimal analytical and reporting abilities. Yeah, no, you're right. I am right, yes, yeah, yeah, yeah. So sorry, but yes, I'm right. Okay, so this is what I need to start doing, okay, is just start writing stuff down.
Speaker C:Yeah, and that's sort of project planners and project managers of very large programs. This is exactly what they do. They have, they've been doing it a while, or they do it for a company that's been doing this sort of thing for a while. They have a big catalog of data that they can use to plan similar jobs. So, yeah.
Speaker A:Okay, look, we need to wrap up. And so how do we want to sort of finish this off? How do you want to round this off?
Speaker B:Well, I think it's broadening it even further and thinking about, you know, how it is we can prevent things from spiraling out of control and becoming, you know, a small problem becoming significantly larger. And you look at, you look at events like, you know, geopolitical events like the Arab Spring, and that's spreading across, you know, So you look at things like? Look at events like the Arab Spring, and, you know, disorder spreading across the Middle East and North Africa and then turning into civil wars and conflict and subsequent disorder and thinking, okay, well that's, you know, Why is it that that level of disorder doesn't continue? And we don't have people engaged in civil wars for forever. And why you don't have the disorder spreading across the planet and suddenly we're back to a state of nature and everybody, you know, murdering one another. What is it that prevents that from occurring? And how can we maximise those kinds of firebreaks within any system to prevent, you know, wildfire effectively spreading through a system?
Speaker C:And there are, I mean, it's a whole other podcast, but there are sort of parts of systems theory, systems engineering, which the whole discipline is looking at complex adaptive systems and systems that are inherent, complex, but inherently stable. They have a sort of some sort of internal feedback, which keeps them on a level. But I'm going to be invited at the end to, so I'm going to get a point in. Yeah, go and get your point in. But I think there are also interesting behavioural things. So aside from biases, like the planning policy and optimism bias and things, there are interesting behavioural things when you're in a collaborative environment, a collaborative team. So we do lots of projects with other companies, similar to our small companies, and we organise the work. So we're doing task A, another company does task B, and another company might do task C. And in that sort of environment, there'd be a natural tendency, if you said, OK, task B, guys, can you deliver your thing by next Friday? Does that sound reasonable? Yep, sounds reasonable. OK, we'll expect it on next Friday. When you engineer a deadline like that, there's a, you're sort of engineering in a not before kind of, people often see this as a not before sort of date, rather than a sort of, than a target date that you, the last possible date and you could get it in earlier. So you're sort of, you're saying, if a task is actually easier than the two weeks it takes to get that task done, but they're not in any way incentivised to get it done early, because you've given them a sort of, a chip to say, yep, don't need it before that date. And that's an interesting, and that's, in project management, you always try and look for ways of incentivising people to deliver early, because that's the way you get programmes delivered early and under budget.
Speaker B:And in the train example, the, why trains don't get earlier is because there's a timetable. So if you turn up and leave before a train is scheduled to leave, the passengers won't be there to get on it and will be quite rightly miffed. So actually, you know, this sort of not before timing is, you know, a good example of why trains might find it difficult to, to, you know, on balance, they can either be on time or late, they don't have the other side of the equation, which is the capacity to be significantly early when everything's going well. So the whole system is biased towards things, things being late.
Speaker A:Yeah, yeah, yeah, yeah. And one of the things you said, this is as often with these results coming back to human psychology, and it reminds me of speed limits, is that they're often treated as a target, rather than a limit. You've got a sort of free pass up until that point. And, you know, but at that point, no, no, no, not past that. But, but again, because that's treated as a target, so it's more, there's more bias to people going over that. Yeah, so, yeah. Okay, so let's round this off. Yeah, I just want to round it off with this. So given that you cooperate with and collaborate with other organizations on joint projects, and given that what you've just said about deadlines and other groups meeting deadlines for a whole project to move forward, given that one of the things you specialize in here is things like decision making and making the right decision, and I guess, in this case, producing something on time. Do you find that other organizations that you work with are worse than you guys at working to deadline? And are you, if so, are you free to comment on that?
Speaker C:No, because, well, we're, Or are you just as bad as they are? Well, if we weren't picky about who we worked with, then we might find that, but we're careful about who we collaborate with. And thinking back to days when in large corporations, corporations and the civil service, where a lot of people aren't terribly incentivized at all to do anything, you know, beyond, above and beyond the minimum, then, yeah, you set a deadline, then you can expect it exactly five o'clock on the day of delivery, rather than, oh, I could get that done early. Would you like it early? Is that helpful? That is rare. But as a sort of manager, that's kind of your part of your challenge. If you're able to, if a task that you've set five days for, it could be done in four, why not give the guys a day off, if they get it done in four, just give them a free day.
Speaker A:So, yeah, on that note, incentivizing people, giving days off. Have we finished the podcast early? Can we go now? Yeah, actually, this is a good example, actually, is that I wanted to make this podcast shorter than some of our others. And actually, I've completely failed to sort of manage that. And we're actually finishing exactly the sort of time that we normally would. So I don't know if that connects to what we've been talking about or not. I suspect in some way it does. And to my own analytical reporting timing skills.
Speaker C:I was in your interest to make them shorter, because you have to edit them. Presumably they get harder.
Speaker A:Yeah, why do you think I'm pushing for this?
Speaker C:They get harder, the more people ramble on, like I'm doing right now.
Speaker A:But you know who I blame for this? And it's not myself.
Speaker C:I blame Nick, because he's not here.
Speaker A:No, I blame you, right? And the reason I blame you is because of your socks. If it were not for your socks, that added at least another three minutes on.
Speaker C:You brought them up, right? I mean, my socks were there. You didn't have to mention my socks.
Speaker A:Well, I had to, because I did have to, just because of the irrationality of wearing socks on a hot day. We can edit out the socks. Then they're staying in. Right. On that note, so I'm Fraser McGruer. I've been here with Peter Coghill and Chris Wragg of Aleph Insights. Thank you, as always, for listening to the Cognitive Engineering Podcast. And until next week, bye bye.
