Sessions is temporarily moving to YouTube, check out all our new videos here.

Modelling with Pencils and JavaScript

Jonny Arnold speaking at London Node User Group in February, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Often the work of a software developer is to write down complicated things in an unambiguous way. In this talk the speaker would like to remind you about mathematical modelling - writing down mathematical relations that approximate a situation - and give a real story about how he should have started with a pencil rather than a keyboard.


- [Johnny] Hi everyone, my name is Johnny. I'm going to be talking a little bit about thinking in terms of models. A way of, hopefully, speeding up the way that you develop code, and will hopefully lead to clear thinking in the future. Just as an introduction, my name is Johnny, I have worked at Trussle for about nine months now. Trussle are an online mortgage adviser startup thingy. You can go to and find out, in hopefully two minutes or less, how much you can afford to buy a house. And I would encourage you to do that at some point during this talk because it does come up a little bit later on. So that's Before that though, as it was alluded to in the introduction, I was a scientist and that's, I mean, that's a bit of a lie, I did a science degree and a bit of a summer school a bit in the middle, but that counts as a scientist, right? And one of the things that gets drummed into you as a physicist is this idea of model thinking, coming up with toys, I suppose, that allow you to simulate real world behavior. And I'll be talking a lot more about that. Why do I think this is important? Well, the importance that I think about it is that I see a lot of people writing a lot of code and not necessarily thinking too hard about what they're writing. Quite often they'll write the smallest amount of code that fixes that Jira ticket or something like that. And I myself am guilty of this as well. But I'd like to go over some tools and techniques that will hopefully allow you to think a bit clearer, make your code a bit easier to read in the future, and explain a little bit about why. So let's start. What is a model? So the first thing you do when anyone is faced with a definition is to go to Wikipedia. Turns out Wikipedia has a lot of definitions for what a model is, so I made one up myself. And so here it is: A model is a simplified system that mimics some behavior of a real system. And the keywords that I think are simplified, there's no point building a model if it's going to be more expensive and take longer to build than the real system. And mimics some behavior of a real system, in that, it doesn't need to just be a toy, it needs to be a simulation, if you like, it needs to be something you can experiment with, and then take those experiments into the real world. So here are a couple of examples of what models are. Here is, quite literally, a model. This is an architectural model of a building. These are built, first of all, to see how cool your building looks from a helicopter, but also to do things like check what the lighting looks like. They've got lamps that look like suns, which they shine on their model to see how it looks in the sunrise and sunset and things like that, and then there's also a structural aspect because if your building falls down in the model, you should probably not build it for real. Another model is this popular board game, Monopoly. It takes the rules of property trading, simplifies them greatly, and then turns it into an allegedly fun game to play. I'm a physicist, I had to get a block on an inclined plane or to people who aren't physicists, a block on a ramp. This is a mathematical simulation, the idea is that you can write down equations that govern how that block moves as it goes down the plane or up, depending on the gravity of the situation, and then work out how fast it is, what position it is after a certain time and so on. And this is different to the other models because you can solve them. So there is an answer. You can find out what the speed is at the bottom there, and you can do that by building this model, and then kind of running the simulation forward. Here is the only slide of JavaScript in my talk. Sorry, everyone. This is a model of a bank account. I'm sure you've never seen this before. Here is the balance, it goes into the constructor, you can get your balance, you can deposit money, you can withdraw money. It's a model, it's very simplified. I'm sure you can spot some mistakes. And it turns out there's lots and lots of different ways of representing models. This is the Wikipedia page for model, and it goes on for another two pages. It turns out there's lots of ways of representing a model, so when we're talking about what a model is, it's actually this simplification into a toy, if you like, rather than its architectural model or a board game. So that's roughly what I mean by model. It's a simplified system, it mimics some behavior of a real system. All well and good. But why would we ever bother in the first place. After all, if you've just told me that JavaScript is technically a kind of model, surely I've been writing models all the time. And to do that, I do a slightly complicated thing. So along the different layers here, we have different ways of writing down stuff. I suppose you start at the bottom with knowledge, stuff that's in your head. This is very easy to acquire and change. So for instance, if I tell you to imagine a blue circle, and then tell you to imagine a yellow circle, it is very quick to change. Whereas if that was in code, it would probably take 30 minutes with the deployment and the tests running, and things like that. The downside of having all your stuff in knowledge is that, it isn't a system. It doesn't necessarily consist of a set of components and as such, it can't really be tested as well. Now, going all the way to the top layer here, the code. You could just write code straight off, but it's expensive to build and change, as we all know. The plus side of this though is, it's a testable system and you can even write ultimated tests to make sure that it's always correct for whatever definition of correct you are going for. So models kind of sandwiched themselves between code and knowledge here. They have the advantage of being quite cheap to build and change, depending on whether you are using glue and sticks and stuff, or whether you're just writing math, and it's also testable. You can run experiments, either in your head, or using mathematics or something like that to test whether this model has the properties you want, and also to find out what properties emerge from the system. So that's why I think models are awesome. Now, I would like to try and tell you a little bit about how we can build them. And to start, I go to the 13th century, naturally. This is Sir William, sorry not Sir, It's just William of Occam, and he was a 13th-century friar, philosopher, whatever you want to call it, he thought a lot. And one of the things that has been taken along by the science community, I suppose, is the idea that if you have two models or two systems, and one system has less prerequisites or assumptions than the other, you should take that one. And in layman's terms, simpler is better. Scientists like to make it more complicated and call it Occam's razor. So we'll be taking Occam's razor and we will be applying it to the art of model building. So here we go. Start stupid. And I mean really, really stupid. If you're building a task management application, you need to tell me why a pen and paper won't work. This is how stupid we're talking here. We want to find something that's so obviously wrong, that we need to break it immediately. And that's what we do straight after. We say, "Well, here is this thing that doesn't work for our task management application. We have two offices, for instance. How are they going to share their tasks between one another?" And then you've got to fix it. Okay. So maybe pen and paper with a little naïve, but maybe we can just do it via e-mail or something like that. And you go through this several times and I mean actually quite a lot of times. You should probably start doing this in your head, so you can iterate really, really quickly but, after that, you need to make it tangible, which is my 11 o'clock at night way of saying, write it down. If it's all in your head, then turn it into some words or some equations or a diagram, something like that. The reason is that, writing things down or drawing diagrams makes things much more concrete. And you can see very clearly when things are wrong. The next thing to do is iterate again. As in, literally go from the start again. Start stupid again and do another set of six as you go through here. The reason for doing that is that, if you have two kind of thought processes and they converge to the same solution, you're probably onto a good thing. Similarly, if they're completely diverge, then you've got a very complicated problem, and you might want to pick bits from one and the other to make your real system. And you can keep doing this as many times as your manager will let you, until you've got something that you think is right. And only then should you start writing the code. So let's put this into practice in the way that only a speaker can, by doing it retroactively. This is a case study that we did, and it's about the Trussle Affordability Calculator. This is what it used to look like, unfortunately it's a bit grainy, but you can see that it's kind of a drop-down formy thing. Basically, this is a way of finding out how much you can afford. This is what I talked about at the start of the talk. We'd ask you a bunch of questions about your current situation, and then at the very end of this, once you've got rid of the cookie banner, you will get a valuation. Thanks, Zoe. With a £40,000 deposit, you can buy a property valued at up to £230,000. That's the goal, If you like. This ran into a few problems that we weren't really sure about. So, for instance, lots of people weren't completing the form. When we went into user testing, for instance, we found that this format of showing one question after another led people to think, "When will it end?" Which is a shame, because I thought it was a really cool way of showing a form. But, yeah, it turns out that the really good ways of showing forms have been done. So my task was to make this better, essentially. So I started stupid, broke it, fixed it. I started with what we had at the moment which, to be fair, I shouldn't have probably called stupid, but I did. And then, break it, kind of break it down, I suppose, into the constituent parts. And one of the things that I found out is that of the seven questions that we asked, only two actually went into the calculation of what your affordability was. So that was a great start, I got rid of five-sevenths of the page, which was very nice and kept going down that route. We iterated. All of this mathematics was just done in JavaScript code, which is all well and good, until you need to check it, for instance, or rearrange it. So, one of the things I did, and that is literally the piece of paper that I wrote down, admittedly draft four, which is why my handwriting looks nice, is write out the individual equations that govern this affordability calculation. Turns out it's not straightforward, which is annoying. The next thing was to make it tangible. I'm hopefully going to go to a demo. Demo, can you hear me? Cool. We're here. So this is a really, really, really cool tool if you're doing any kind of mathematics. This is the Desmos calculator. I hope I pronounced that right. And it allows you to fill in mathematical expressions and then use variables to find out how these... That one doesn't work, to find out how a model changes. So, for instance, in this graph you've got property value along the bottom axis, the amount you're allowed to borrow on the other axis, and the green line, you want to get as high up that green line without entering a gray shaded area. I could go into more details, it's boringly complicated, so I won't. The thing that I wanted to get across here is that, making it tangible, turning it into something you can play with and experiment with is really, really useful. That was a lot more useful at finding my errors than writing out lots of mathematics, and rearranging, and plugging in a few values. You can do it really quickly there. And we iterated it again. It turned out that these calculations were kind of strewn across a lot of our codebase, which was good in a way because we had lots of different iterations of the same calculation, but wasn't great because some of them weren't correct. So we took a few of them, we put them together, and now we have a single affordability model. Basically, a JavaScript class that has all of the relations that handle all of these different variables together. You can plug in your inputs, you can ask for your outputs, and it will throw an error if it doesn't have enough information. One of the things that I did recently, another demo, is...and by recently, I mean five hours ago, is put together something called Mamo, I'm surprised I got a four letter MPM package as well. This is a mathematical modeling helper, which allows you to define a mathematical model in terms of JavaScript functions and constants, and then just give it your inputs and ask for your outputs, and it will try and figure out, based on what you've told it, how to work out that equation. It's very early stages, as I say, five hours old and so be nice to it or contribute, that would be even nicer. Cool. This is the finished product, by the way. This is what the website looks now, if you went to try and find out how much you can afford, and I hope you'll agree, because we spent plenty of time on it. It's a lot quicker to get the result that you need. We found that the uptake on this is much, much higher, and people like to play with this and experiment with this as if it was some kind of a model. So that's roughly what I wanted to say. I want to go into stuff that's a bit more abstract and fluffy. Why should we be doing these things? My main take away from this is that, the active mobile building will allow you to think clearer. And if you have clear thinking, then your code is going to look a lot better as a result, because you know what you're doing. I'm sure all of us have looked at files in our codebase that have been written by four or five different people, where maybe two or three of them were very opinionated about how it should have been built, and now have two concepts that have been effortlessly smashed together in a way that no one now understands what is going on. In these situations, you need to find out which model was more simple, take Occam's razor, for instance, and then see how you can adapt it, see how you can test and iterate through these things to make the model correct and then implement it in code. That's about it for me. So thank you very much. And I'm sure I've gone well under time, so there's plenty of time for questions. Thank you very much. Any questions? Yes. - [Audience 1] So, you know, Mamo, What's it called, Mamo? - Mamo, Yes. - Have you [Inaudible] like it? - So the question was, can we add some FOP stuff to make it a lot more interactive, I suppose. - We can do that. I'd literally put this together, 20...not very long ago, so it was kind of just the idea of it. And there's no reason why that can't be done. It's all pretty performant, given that it's only about 60 lines long at the minute, so I'd be very disappointed if that were any issues there. But yes, there's no reason why we can't do that, and it would be cool to build something like Desmos, where you just throw in a model and see what happens. Yes. - It was a team effort, of course. - Team effort. - It was one of those things where, when we found an issue or something like that, we wanted to...we just added to it without really thinking about it, and that was where we shot ourselves in the foot. Now, there were reasons for having those questions that we've thrown away now. So, for instance, we did a lot of pre-checking. If you had bad credit, for instance, we wouldn't tell you how much you could afford, because you probably wouldn't be able to be lended to. So that was kind of what those questions were for. Asking what their name is, yeah, we probably shouldn't have done that anyway, but we wanted a kind of personal touch, and that was one way of doing it. So yeah, it was a bit of a team effort. And just that kind of scope creep, it happens to pretty much every product I've seen. You ever been through the menus in Jira? There are so many, there are so many options. I looked down today and it was so many. Sorry, any more questions please? - [Audience 3] [Inaudible] - No. That's cool. The question, statement, I suppose, was, there are a lot of kind of notebooking tools, so these are things that allow you to build models, like I've defined very, very quickly. And kind of having a trail of thought. It's meant to be like a lab book for scientists, and whether there's any available in JavaScript, I don't know, is the answer. Like, I wouldn't be surprised if someone had taken a tool like D-3 and put together some kind of physics simulation toolkit or something like that. It tends to be with these things that people build their simulations by hand. It would be nice if there was a toolkit. I don't know of any, I'm sure there [Inaudible]. Yes. - I mean, you can use TDD for this if you like. I've mandated TDD before you touch your computer in that you are putting together a model and then testing it harder and harder and harder. Right? And that's exactly what scientists do. TDD isn't a new thing to scientists. They have been doing it for a very long time. So I suppose, yes, I do mandate TDD, I think is a great thing. No, I don't do it all the time because I'm a developer and I'm human. But it is useful, and you can see the results very, very easily, I suppose. Anyone for any more? Good stuff. And I'm off. Thank you very much.