Computational Conversations EP#4 | Selecting the right tool

Nobody is even making a conscious choice that these people in the Department of Health had been doing their kind of office budgets in Excel. And so that was just the tool that they were using when this new problem came along. Hi, I'm John McLune.

And I'm Conor Wolfram.

And today's computational conversation is going to be on the topic of tool selection trickier than it might at first appear. Now, the reason why I picked this one, I was intrigued by a blog item you wrote some time ago that was quite impassioned about a minor mess up in the UK government statistics. And for those who are not in the uk, I should probably explain the backstory.

It wasn't that minor actually, John, I just point out, but go ahead.

So we're in the early days of COVID numbers are increasing. The government's tracking this and reporting daily. And for a couple of days it seemed like the government's tactics were winning because the COVID numbers stopped going up dramatically. And then after about two or three days, it was revealed that there'd been a mess up in the figures because the figures were collated through Excel spreadsheets being mailed from each of the local authorities into the central government authority, and these had been pasted together to produce the final numbers. But it turns out there's a maximum number of rows in an Excel spreadsheet and after the epidemic had been going on for a few weeks, the the spreadsheet could no longer hold all the data. So it looked like the numbers weren't going up. And in fact it just simply was. The Excel spreadsheet wasn't going up. Now, you read a lot of educational failure into this and perhaps you could tell me what your viewpoint was.

Well, I mean, by the way, it was Excel 2007 version, I believe, and obviously this was some time past that. This really pissed me off for all sorts of reasons. Firstly, the government spent a lot of money on technology and data and other things, and the fact that it was in such a degradated state was a pity. Now, of course, they didn't know a pandemic was coming per se, so they had to scramble quickly to do something. So in a sense I'm less upset with the immediate scrambling and whatever tools they could lay their hands on than the fact there was no prior planning and thinking about what to do to set this up and that anybody should think that, no, any Excel just wasn't built for this purpose. Right. The thing that struck me is this. There's a lot of mistakes in the modern world. We depend on our automation, our machinery and the machinery is very, very complicated and you can't know exactly how it works or all sorts of other things about it. So you've got to build up experience and judgment and processes for figuring out what to select. And I just don't think we're doing that very well. And I think it's part of education, right, education. Part of it is to enrich life and to build experience, accelerating a sense of experience, what to do. And yet this seems like a key area. How do you select the right tool for the job? Not happening.

I think this one less of an experience issue actually more of a kind of lack of process, which maybe you need to have experience to run processes. But I think you're being a bit forgiving about the scramble because this was some weeks in and in the first few days you're in scramble. But the fact that this far in they had not built any QA processes to check the data that they were publishing.

No, no, that that was bad.

They should have caught that the moment it started going wrong. And, and really it was evidence a lot of this was being done manually. And you know, when I'm engineering things, every time a human's involved, it's an opportunity for failure. So we got copy and paste manual work without any checks to make sure.

That it's, I mean it's completely crazy and billions of pounds were being spent on this. But the thing was, it was a sort of funny mixture as you say. There certainly was ham handedness in putting the thing together, but there was also sort of lack of understanding of how difficult it might be to get the right thing. And also this concept that data, it's just like fine, we just have data in a total mess in silos, we don't know what to do with it and we're just going to sort of throw it in and hope it produces. Is the right answer I think is fundamentally flawed. And it's flawed in the age of LLMs like ChatGPT and things in fact possibly even more than it was flawed before. The fact they've got a nice gloss and surface on them, a veneer doesn't make the data right. And we've argued a long time you should have computable data ready to compute from. It needs to be put together. It's like tarmacing roads. Don't build the whole road network and hope everybody's going to tarmac it well because you'd probably be upset with the number of accidents. That's exactly what seems to be happening here.

So to me, like, there's three different angles on this. There is the choosing the right tool for the job, there's helping people understand reliable process engineering, and then there's the judgment to know whether the data means anything at the end. Now, yeah, let's do those in turn. So not getting into the details of the pros and cons of Excel versus other applications, how are we supposed to find the right tool today? That seems like a very interesting challenge in its own right.

It is an interesting challenge and it's hard because really what I think you're wanting to do. Well, there are two things. Firstly, there's. You're trying to think about what workflows are you trying to optimize, not only now, but potentially to the future. Because you probably select your tool if you're building a lot of stuff around it, you might select it for a decade or more. And so you're trying to imagine like you're trying to imagine ahead there might be a pandemic. What are we going to do with this data? What are we going to do with it? Will this be a good enabling tool for that future case? I think it's a little bit like writing legal contracts. By the way, when you write a legal contract, one of the things you're hoping to think ahead to is what are all the cases that might occur that I'm trying to cover off? And this is a little bit like that sort of thinking process in a sense. So you're trying to imagine you and other people using it and what the hell they might do with this for cases that haven't arisen yet. Now the other thing occurs to me is there are different styles of failure mode. There's what you normally see, which is just inefficiency and I'm cutting and pasting this and it's kind of like some of the columns will get lost because they didn't paste the right thing. Sort of everyday incompetence and inefficiency. But the thing you've also got to worry about is catastrophic fuck up. And if you've got in complex data with poor checking, with poor understanding of the workflows that you really want, the catastrophic fuck up scenario is ever more likely. And the more complex and sort of automated the thing looks to be, it's not really automation. It's like the more layers it's got, the worse that can be. Also again, there are all sorts of types of ways that you can get that sort of mess up. It's kind of like you cannot realize the tool will fail in a particular direction. You cannot realize that in a particular day the data wasn't going in right. Et cetera, et cetera.

So you're talking about a lot of depth here in how to choose well, but I suspect that it's failing level even before that, that nobody is even making a conscious choice that these people in the Department of Health had been doing their kind of office budgets in Excel. And so that was just the tool that they were using when this new problem came along. And there was not even a conscious question of how should we do this? They just do it in the way that they're doing everything.

I mean, as you point out, I think a lot of what's happening is people. It's hard to change tool because the tools are complex. At least that's people's perception. And it's hard to then pick the right tool. So what do people do? They stay with what they know. What they know in this case was Excel. Now, it's a bit sad that however much being spent in the interest, 130 billion pounds a year, you know, I mean, one of the. Again, let's go into various other things. What should be centralized and what shouldn't be. You know, there are a lot of things I think it's much better to decentralize. But I have to say, sort of how you organize your data, one of the great advantages in a place like UK is you do in fact have centralized health data in principle, and organizing that well gives you a massive advantage. So don't leave it, as is often done to each hospital, and hope that some siding in the Department of Health will do it. Or as a conversation I had years ago with the, then I think, head of data in the nhs, they said, no, no, we're just going to have a market that will figure out what to do with it. And we don't really need to organize it. It'll just sort of be done by the market. No, that's the wrong approach for that particular piece of the ecosystem, in my view.

So it sounds to me that what you're putting a finger on there is a cost return of the effort of making a decision. Because if all you're doing is your personal finances, then that effort of designing on better software is outweighed by the benefit you might get. But the more things get centralized, the bigger they get, the more it's worth trying to optimize.

Yeah, I mean, there's always a question. We have this problem inside Wolfram, right, which is what you force People. So what do you centralize systems and where do you let people just pick their own? And there is a big trade off there, you know, I mean, for example, project management systems, as a good example. It's a mistake to let everybody choose their own most of the time because you need to coordinate between different departments and if it's all in different systems, it gets lost. But on the other hand, some systems perform better for some kinds of departments, et cetera, et cetera. But there are other places where it doesn't matter much. There might be economies of buying the thing all in one place, but then the economies of people using what they know might be better. But the problem is, I think where there's a lot of hidden complexity and it's hard to evaluate the outputs, that's where you've got to be careful and. Or where you've got lots of people who have to work together and stuff around. Big data is often that. And it's funny these old adages and how they change. So of course the traditional adage has been a bad workman blames his tools. I wonder if the modern adage is much more like a bad workman uses the wrong tools for the job because actually that's the hard thing to do.

There's a challenge I think, in software as well, which has not followed the standard path of industry, which is that most technologies have consolidated over time. That, you know, when you, in the 1920s, you could buy all kinds of different brands of car and over time, because the engineering required to do a good job grew, then the world consolidates down to, I don't know how many major manufacturers there are of cars now. 20. And you know, while they have different models, you don't have these corner stores that you can choose from. And software for a while has sort of gone that direction. But at the same time there's been this proliferation of small tools and things that have big claims and they're also much more complex. You know, what is there to choose between cars? Most of it's emotional grand attachment or the size of the engine, or whether it's got so many cupholders. It's pretty basic decisions that you have to choose between. Whereas in software the details can be very complicated between one solution and another. How is anyone supposed to be able to cope with that?

Well, I think there's several parts. Firstly, I think there's stuff that gets consumerized and in a sense parts of cars have got consumers. Of course, car thing is interesting because now there are more manufacturers starting because the technology's fundamentally change or part of it is to electric cars. And so that's a whole different ball of wax, so to speak, or melted wax, depending on what happens. I think the problem is there are certain things where in a sense big centralized control of them and complexity is important. And I would claim computation is one of those things because it all has to fit together and it has to fit together over a long broad scale and over a long time period. And having random people do random things where they haven't designed it very carefully, it's all to do with how important the large scale design is, I think is one key thing. And also whether the automation advertises where it goes wrong, that's a very, very critical thing. So actually there's a nice example we often show right about the collapse of significance. If you take a simple calculation and you basically run it lots of times there are many such things where you can chop the number so that it moves along and you lose significance. And if you try, we have an example actually against Excel, I think, although many numerical systems do the same thing where you run this, I don't know, 20 times and the answer should be, I forget the thing we're running.

But the answer, it's arithmetic you can do in your head, but it comes out wrong.

In Excel the answer should be like two each time. And after about 20 iterations of this, it goes to about 10 to the 19 is the answer in Excel. So that's bad. I mean, in this particular case, quite easy to see that it's wrong. But if that was deep inside something, it's hard to spot. In Mathematica we automatically track the significance of the arithmetic. So it just goes down, you see it reducing the number of decimal places until eventually it says can't help you because the significance collapsed. So it puts up an error and basically refuses to to produce an answer to this. So that's very helpful because you can tell there's a problem. So that's an example of automation that kind of helps you to figure out where it's gone wrong as opposed to just goes on. And this is very, I mean, one of the difficult things selecting software is. And so one example I love to give is the Instamatic camera. So in my youth and yours, you know, I don't know whether you had an instamatic camera with 110 film.

It was a horrible thing I did at one time. Yes.

Anyway, you took a picture, it didn't do anything. It didn't measure the light, it just didn't have focus it just took the picture. But it has a big enough depth of field and sort of big enough latitude and exposure that hopefully something come up. But basically every picture was bad. The interesting thing now is you take your iPhone or whatever it is, and you basically do the same thing. You hold up, you look through it, you press a button, and almost every picture is technically good. Now, on the surface, you're doing exactly the same thing there. Right. But there's a huge pile of automation sophistication in the iPhone and absolutely zero in the Instamatic camera. And the result of that is it does a fantastic job, you know, in many cases better than you could manually do technically.

Yeah, but I think you're on a different track though, because I totally agree that automation reduces the complexity and that automation is what allows us to be able to use much more complicated tools. But actually, as you know from challenges we have in the marketplace is that it actually adds to the complexity of that decision because we now have to explain to people these issues about automation. And if you take the example of the cameras, there was a time, I'm sure, where that little 110 camera was saying, takes pictures automatically. You don't have to adjust any settings.

No, but the point.

And the user has to learn that there's a difference between powerful automation of real autofocus versus fixed focus. And. But the point is, in the end.

You'Re going to get a much better result. Right, with the fancy automation. I mean, even that, you know, like professionals now use a lot of this automation, which they didn't initially, because I agree with you.

But how do we explain to people who don't understand that that there is a difference to have proper automation that really does the right thing versus something that says AI inside. Don't worry.

Well, I think you show cases like collapse of significance. But it's tricky, and it's very tricky when people don't have a background, an educational background, which has forced them through a lot of these decisions. Because in the end you get a certain amount of experience. I mean, the thing with cars, people have bought cars for a long time now. It's a very consumerized market. There's certain things you look for in buying a car which helps guide you, even if you don't know anything much about cars. So that's gone and got consumerized out. When you talk about somebody's software selection, that hasn't really happened in the same way. And so you claim it to have your own experience.

Yeah, we have to have the experience in detecting the nonsense Marketing from the stuff of substance.

Yeah, I mean, look, there's complete bullshit talked and there's bullshit about the automation, but it's hard to see because you don't notice until you've gone some far down track. You tried the hard case, you've tried the case where you hadn't realized that Excel 07 was limited in number of columns, et cetera, et cetera, even though it was completely the wrong thing to do anyway for all sorts of reasons for that data. So I think that's a typical thing. But I think, you see, we can improve that a lot in education. Where in maths, for example, do you have outcomes about managing computations as part of what you're learning? Never, because you're doing simplistic things without a computer. But how you manage the machine is a critical part of what people need to learn. And how you manage the AI is very critical as we enter the AI age, because essentially the AI is your employee, hopefully, as opposed to, well, hopefully it's not your manager. And it's important that you figure out what to do with it.

So to what extent do you think that learning how to manage the computation is really about those kind of process engineering type things that I talked about at the beginning of knowing that you want to avoid manual steps and how to do QA versus building, the experience of detecting marketing lies from the reality and knowing how to spot when your tools fail?

Well, it is a complicated mess. I mean, to me, when I think about this the hardest, it depends what technology is, but I usually try and look into the technology, whatever I'm doing. So I reckon I'm not bad at bullshit detection on the marketing because I ask very specific questions about what does that mean? How could that possibly work this way? The thing that I do find very difficult, and I think so, is everyone is rearchitecting a workflow. So here's the normal thing that happens. You have some old piece of technology, you ran a workflow, the workflow was very suboptimal, but it was okay with the technology you had. So you just go on, this is what you do. New technology comes along and the first thing you do reasonably is to substitute it for the old technology. It has some improvement, it's a bit faster, something happened that's slightly better. But of course, then what's difficult is to zoom out, step back and say, right now I've got this brand new technology which enables potentially many new workflows. What is it that I actually wanted to do? And if I do that new thing what are the potential catastrophic failures that we may have? And that's a step that takes people a long time to do and also clouds their view of what technology to get. And so that's why I think this is a very important part of education. Part of what you need to learn through the years at school is which tool to select for the job, particularly software tools, but any tool. But so in order to do that we've got to expose people to the breadth of tools. If we haven't done that, they can't try that process.

So before we wrap up, let's just end with one question which is if we aren't going to improve education, how much of this issue is about giving people the kind of, the somewhat kind of process, formal ideas of here's the kinds of ways you might validate kind of problems you might experience and how to test them versus just giving people experience and letting them break things and things go wrong on them so that they have a more kind of experiential, visceral feel for. That's the kind of problem I had in the past. Is it something.

No, I don't know.

Is it something that we help people to discover?

I think it's more of the latter in this case. I think there are some basic types of errors that people need to be aware of like the basing inefficiency versus the edge cases, that type of thing. But in the end I think a lot of it is, you know, testing it out, seeing what goes wrong, hearing about where, you know, where there were mistakes made in the past and what went wrong and trying to abstract out from those what, what the base cause was. That's my view. I don't know you well, I think you're usually more of a pragmatist than me.

And for my pragmatic role of doing projects, it's the, it's the mess ups I've made in the past that the most painful ones are the ones that I don't make again. Because you remember them and you instantly smell when you're going close to that problem again. So I don't know whether education could have prepared me better, but I've had many years of making mistakes now to build that kind of knowledge base.

Yeah, I mean in the end it's experience education. I hope part of its function is to accelerate experience in particular areas. And so this seems a ripe area for that. And let's hope some of the people who get accelerated experience go and select stuff for the government in future.

Okay, great. Well, I think We've only scratched the surface of that one, but thanks for listening, everyone, and see you again next time. Yep.

Good to see you. Bye.