The Limits of TimePosted: November 9, 2012
I’m writing this on Monday (and Thursday night), after being on the road for teaching, and I’ve been picking up the pieces of a hard drive replacement (under warranty) compounded by the subsequent discovery that at least one of my backups is corrupted. This has taken what should have been a catch-up day and turned it into a “juggle recovery/repair disk/work on secondary machine” day but, hey, I’m not complaining too much – at least I have two machines and took the trouble to keep them synchronised with each other. The worst outcome of today’s little backup issue is that I have a relatively long reinstallation process ahead of me, because I haven’t actually lost anything yet except the convenient arrangement of all of my stuff.
It does, however, reinforce one of the lessons that it took me years to learn. If you have an hour, you can do an hour’s worth of work. I know, that sounds a little ‘aw shucks’ but some things just take time to do and you have to have the time to do them. My machine recovery was scheduled to take about four hours. When it had gone for five, I clicked on it to discover that it had stopped on detecting the bad backup. I couldn’t have done that at the 30 minute mark. Maybe I could have tried to wake it up at the 2 hour mark, and maybe I would have hit the error earlier, but, in reality that wasn’t going to happen because I was doing other work.
Why is this important? Because I am going to get 1, maybe 2, attempts per day to restore this machine until it finally works. It takes hours to do it and there’s nothing I can do to make it faster. (You’ll see down the bottom that this particular prediction came true because the backup restoration has now turned out to have some fundamental problems).
When students first learn about computers, they don’t really have an idea about how long things take and how important it is to make their programs work quickly. Computational complexity describes how we expect programs to behave when we change the amount of data that they’re working on, either in terms of how much space they take up or how long they take to compute. The choice of approach can lead to massive differences in performance. Something that takes 60 seconds on one approach can take an hour on another. Scale up the size of data you’re looking at and the difference is between ‘will complete this week’ and ‘I am not going to live that long’.
When you look at a computing problem, and the resources that you have, a back of an envelope calculation will very rapidly tell you how long it will take (with a bit of testing and trial and error in some cases). If you don’t allow this much time for the solution, you probably won’t get it. Worse case is that you start something running and then you stop it, thinking it’s not going to finish, but you actually stopped it just before it was going to finish. Time estimation is important. A lot of students won’t really learn this, however, until it comes back and bites them when they overshoot. With any luck, and let’s devote some effort so it’s not just luck, they learn what to look for when they’re estimating how long things actually take.
I wasn’t expecting to have my main machine back up in time to do any work on it today, because I’ve done this dance before, but I was hoping to have it ready for tomorrow. Now, I have to plan around not having it for tomorrow either (and, as it turns out, it won’t be back before the weekend). Worst case is that I will have to put enough time aside to do a complete rebuild. However, to rebuild it will take some serious time. There’s no point setting aside the rebuild as something that I devote my time or weekend to, because it doesn’t require that much attention and I can happily work around the major copies in hour-long blocks to get useful work done.
When you know how long something takes and you plan around that, even those long boring blocks of time become something that can be done in parallel, around the work that also must happen. I see a lot of students who sit around doing something that’s not actually work while they wait for computation or big software builds to finish. Hey, if you’ve got nothing else to do then feel free to do nothing or surf the web. The only problem is that very few of us ever have nothing else to do but, by realising that something that takes a long time will take a long time, we can use filler tasks to drag down the number of things that we still have left to do.
This is being challenged at the moment because the restoration is resolutely failing and, regrettably, I am now having to get actively involved because the ‘fix the backup’ regime requires me to try things, and then try other things, in order to get it working. The good news is I still have large blocks of time – the bad news is that I’m doing all of this on a secondary machine that doesn’t have the same screen real estate. (What a first world problem!)
What a fantastic opportunity to eat my own dog food. 🙂 Tonight, I’m sitting down to plan out how I can recover from this and be back up to date on Monday, with at least one fully working system and access to all of my files. I still need to allow for the occasional ‘try this on the backup’ and then wait several hours, but I need to make sure that this becomes a low priority tasks that I schedule, rather than one that interrupts me and becomes a primary focus. We’ll see how well that goes.