I just spent the first week of Summer vacation practising the Swedish national sport of home renovation. It seems that everyone is doing that all the time nowadays – it might be that I have reached the age of family raising where that becomes important, or it might be that it is a general trend that more people spend more time and money renovating their homes. I think it is the second case.
Anyhow, what we set out to do this year was to replace (most of) the twenty-year-old wooden decking on the backside of our small row house with a new one. This was quite an adventure, as we discovered all kinds of interesting designs and problems with the old decking structure. Problems, which do reflect on the realities of computer programming and simulation.
Preserving legacy structures
For the simple reason that we do not want to spend the entire four weeks of vacation building things, we decided to keep the original shed that is located at one end of the decking. Technically, this meant taking a saw, cutting the decking close to the shed, and rebuilding the rest of it. It also meant that we had to constrain the rest of the construction to preserve the original height of the decking, and the thickness of the boards used to construct it. Had we rebuilt everything, we would have done things differently and reconstructed the entire supporting structure of beams.
Now, we were forced to preserve the existing design, which is not quite optimal or fully modern. Very much like how it is when updating a large piece of software. Most of the time, you have to preserve old APIs, pieces of code, and design decisions that are not really optimal or modern anymore. Fixing it means starting from scratch, and quite often it is not considered worth the investment in time and effort.
You also tend to find amazingly poorly done items in old software, and so it was with our decking. A large part of the old deck had sunk some 10cm below its original level. When digging out to find out why, it became apparent that the beams had just been put on a bed of sand with no concrete or metal supports on the part closest to the house. That bed of sand had then been hollowed out by a misconstructed fix to a drain pipe that let the water spill out around the proper drain. Sigh. Not the first instance of poor workmanship around this house… and we had to do a workaround involving bricks, more beams, and a very large load of sand (I have shoveled some 800kg of dirt and sand during this project).
Reflection on simulator construction
The next observation is based on how the decking turned out in terms of the number and size of boards needed to cover the area. I had done some measurements beforehand indicating the width and length of the area to be covered. It looked like a number of 95mm standard boards with 3mm spacing would do perfectly to cover the area and provide a nice even end.
In the end, we wound up buying a small number of 120mm boards for the final row. For some reason, one side was 10mm wider than the other side. Also, the 95mm boards turned out not to actually cover the area quite as well as expected. Due to minor variations between the boards (in practice, they are 94 to 96mm) as well as imperfect spacing and the general plasticity of wood (it is a living material, not lego bricks laid out peg by peg) made our plans fall just short forcing a last-minute change to 120mm boards for the end.
As a simulation expert, you could say that this shows the shortcoming of the analytical approach. By making a single measurement of the width of the field, and assuming a single number for the width of a board, I set myself up for surprises when confronting a variable reality. If I had built a better model of the deck, measuring it at multiple places and measuring my boards and working out on paper – simulating – how they were to be put together, I could have predicted this and bought the 120mm boards in the original load instead of as an afterthought. In principle, this might be true.
But on the other hand, doing that simulation would have been tantamount to actually building the thing. Understanding the spacing between the boards and how their variations interact would have necessitated constructing in my mind, computer, or paper a perfect model of the deck. I doubt that it would have been saving me any time compared to just going out and putting the thing together, especially as the act of putting it together taught my just how variations occurred and how they worked out in aggregate.
I think the same often applies to computer simulation. Yes, you need to have more details and more variation than a simple analytical model. However, you also need to keep the model simpler than reality in order to make it feasible to construct, maintain, and execute at decent speed. Any model will have imperfections where it diverges from reality, and as a simulator constructor the game is not to be perfect but to provide a useful tool to your end users. If it is a bit imperfect, so what, as long as it is imperfect in unimportant ways and mostly provide good guidance. For more on the philosophy of simulation, I would suggest reading a blog post from 2007 about golf games and computer simulation.
So what would a useful model have been for my decking? I guess measuring a few more points would have helped, as well as measuring some set of boards and the device we used for spacing. That might have helped us spot the issue with the too-narrow final board ahead of time. But it was more fun this way, and this is vacation time and hobbyist work and not professional carpentry.
What conclusions can be drawn from this?
- I guess I am a hopeless nerd who can never stop thinking about technology.
- I have a very nice deck now, looking forward to some decent days in the next few weeks to make use of it.
- Building physical things is quite a satisfying experience, even if they do not turn out perfect in all details.