My recent post about obsolescence reminded me of a forgotten Hacker News comment I wrote in response to early news about the ISEE-3 reboot idea. This was back before the effort even seemed feasible, when Bob Farquhar was trying to drum up support. He died last year, and it seemed like, under the circumstances, it was worth reposting.
"But at that point, Dunham says, who knows if the spacecraft would still be alive."
Something about this line struck me. The story is about an "old satellite"; an "old friend", and it needs "old equipment" and "old documents" to be made to run again. That word is packed with a lot of meaning because for us it means not just the passage of time, but maturity, senescence and, eventually, death.
But there's no reason yet to think that the capabilities of the satellite are in any way degraded. Unless there's been some kind of accident, it could well be in pretty similar condition to when it left. It's had a long life, for sure, but in a sense it hasn't aged at all.
Compare that to the situation back on Earth. The equipment NASA used to communicate with the satellite is gone. A lot of people who worked on it have retired. Maybe we don't even have the knowledge left to operate it. If you shift your perspective to that of our old friend the satellite returning home, it's us who have grown old and forgetful while it remains disgustingly young.
And ultimately, this is the story of Bob Farquhar and his creation. Farquhar is 81, the article says, and not in the best health. The satellite is his life's work: he coined the term "halo orbit", proposed the original mission, and came up with the idea for what that mission has now become. No wonder he feels a personal connection to this satellite; it's essentially a part of him.
And if this plan works, who knows how long that part could keep going, bumbling around its lab at the Sun-Earth L1, doing science just like always. Sure, it could be damaged or destroyed, but it'll never get old. Never wonder when the next attack's coming. Never feel a little worse than the day before.
And if we miss the timing window and the next one isn't for two hundred years? Well, who knows if the spacecraft will still be alive? Two centuries is a long time. Longer than we've got, at any rate.
Last time I finished up my art project prototypes, so this week I did something a bit more practical: home automation! I have some 433MHz radio-controlled power switches that I've been using, and I'd been planning for ages to use a cheap 433 transmitter/receiver pair with a Raspberry Pi to automate them.
The first step was to figure out something that would work. This took way longer than I thought. Partly, this was because my switches used values most libraries couldn't handle, and partly it was because a lot of the libraries for this stuff are really rough around the edges. Nonetheless, I managed to figure out my switch codes and set them up with this node library. This prototype was just a commandline tool, but it did the job and I could switch my lights from the Pi.
The next step was to make something easy to interface with. I didn't want to ssh to the pi every time I wanted turn my lights on, so I built a little web server to accept POST requests. I also added support for switching multiple things at once, and queueing the commands with enough delay to avoid putting out garbled unrecognisable signals. Once I had that going I just used a little shell script to curl the appropriate commands at the Pi and now I can switch the lights from my computer. Victory!
There is a central problem at the heart of many of the difficulties I've had with creative work. It's behind my recent writing failure and many older ones as well, but it's also something that's been affecting my prototypes and even larger projects. I touched on related things in The idea triangle, Two kinds of perfect, and Continuous everywhere. This problem sits somewhere near all of these ideas, but I think it's distinct, and particularly important. Here it is:
You can control how good something is, or you can control how long it takes, but you can't control both.
This might seem obvious. Certainly, it seems obvious to me now, but it didn't seem that way before. Sure, we pay lip service to the idea, but think about what happens during a standard top-down project. You figure out what you need to do, break that down into small parts, estimate all the parts, then start working. But what about when your estimates turn out to be wrong, more work appears, the requirements change, and all the other things that happen in every project? Well, one of those two things is going to have to go. Either you can't have it when you wanted it, or you can but it won't be as good.
Agile is all about this second path; it controls how long things take, but not how good they are. By aiming to repeatedly approximate the final product, the idea is that when you inevitably have to make that choice, you will be partway up a smooth curve of doneness over time. By contrast, waterfall-style projects are often not useful at all until they are completely finished. Faced with that situation, you have no choice but to accept however long it will take.
Both of these options work fine in theory, but in practice they both fall to impossible expectations. Nobody's happy with a project that goes massively over time and budget, even if that's how long it always would have taken. And nobody's happy (despite the claims of Agile fans) with a project that doesn't do everything it was intended to, even if it's on time. If you turn around to a client who wanted 5 features and say "well we got 4 of them", that client will turn back and say "so go do the 5th one!" What people want is a project that does everything they asked for while also taking the amount of time they want. Which is too bad, because they can't have that.
Of course, some projects work out complete and on time, which really only happens if the time was accurately determined from the desired quality. If you have a reliable estimation procedure and you trust the numbers, then you won't need to control how long it takes; you just accept the estimated time as a fact. Unfortunately, as in The idea triangle, you can only make an accurate estimate for an uninteresting problem. If your problem is identical to one you've solved before then you know how long it takes, but as soon as you have novelty, creativity or improvisation, your time or quality are going to get blown out somewhere.
So creative work, the kind I like doing, suffers the most from this problem. There are many reasons I aim to build regular productive habits, for raw material, as a motivational trick, and as a way of training my associative self. But these habits often break down, especially when I have other things going on. Framed in the light of this observation, the reason is obvious: a habit requires something to be done by a certain time.
Unfortunately, squared against that is a love of quality, and a tendency to jump at opportunities, whether or not they're within my current context. In fact, I think a large part of what I find appealing about creative work is the ability to make space for these chance thoughts and follow them wherever they lead.
But these two things can't coexist. At some point during a prototype, during a writing session, during any kind of project, that voice will come to me and say "psst, hey, I've got an idea that will make this thing way better". If I say yes, I am choosing quality over time. If I say no, I am choosing time over quality. But I don't want to choose, I want both. So I take the idea and pretend that it won't take longer. When it does I take that time from somewhere else or make a new plan that includes it.
The issue isn't that I would make this choice and then regret it, but rather that I didn't realise I was making a choice at all. Instead, I was unintentionally adding these extra conditions and thereby putting myself in an unsolvable situation. I somehow ended up being the bozo in the room asking for impossible and incompatible things and trying to will myself through the air despite no available physics indicating that I could.
So I resolve to take this lesson to heart. Some things I want done by a certain time, and for them I must be prepared to sacrifice quality, to say no to opportunity, and accept whatever outcome the time allows. Some things I want to be good, to have that essential sense of quality that I find beautiful and motivating. Those things will take time. How much time? I don't know, but whatever it is I must accept it.
This failure was substantially similar to the last: things were looking okay but not fully green, I got busy with some work and then my writing slipped again. The boom and bust cycle is still in force and, while I think the smoothing effect of the mythical future posting plans should help, I also realised something important about the way that time-based and goal-based work conflict that I will write up shortly.
I've been thinking of an interesting project, something to bring awareness to the digital dark age problem. The digital dark age is the idea that changing software, incompatible hardware, and explicit copy protection could mean that there will be some information that, despite being perfectly preserved, will be completely inaccessible to future generations.
A good example of this is the ISEE-3 reboot, where a group of crowd-funded amateurs (with NASA's approval) attempted to repurpose a decommissioned satellite. Unfortunately, the original electronics, software, and technical documents were gone. The electronics could be more or less simulated with a combination of software-defined radio and the dish from GoldenEye. But the software? Luckily, several people from the original project were still alive, and enough documents survived that, with their help, it was possible to communicate with the craft. By its next flyby in 30 years, though, the original engineers will no longer be available. Human life is a very fragile storage medium.
Our loss of knowledge is a loss of value, and I think it'd be interesting to represent that literally, by storing bitcoins in old file formats and old devices. There's an amazing breadth of scope for this idea. You could start with small values by putting a few dollars worth of bitcoins on floppy disks and cd-roms, forcing laptop-owners to hunt for disused PCs or more dongles. You could put higher values on minidisks, zip disks, 8 inch floppy drives, Diablo drives, etc. It works for software, too: bitcoins embedded in VisiCalc files, Virtual Boy roms or Multics boot tapes.
Of course, this is all a bit self-defeating; in order to put the bitcoins in those formats, you need to be able to write them, which means that the information hasn't been lost. To really make the point, you want a significant amount of money locked away in hardware or software that nobody can read; a kind of buried treasure hidden in plain sight. You could do this by figuring out how to write an old format or interface with old hardware and not telling anyone else how, but that's really the opposite of what you want.
Instead, you need to think long term. Produce the works now, keep them in storage, and release them on a schedule. A floppy disk in the year 2016 might only be worth $1 because we still have lots of readers around, but what about in 2050? 2100? The promise of higher-valued bounties waiting might act to encourage keeping that knowledge around, or at least to think twice before discarding it without any thought for the future. You could even do similar things with online services; if you're worried Twitter is going to go bust, encrypt a bitcoin wallet address using a bunch of randomly chosen tweets as keys and wait a decade to publish the tweet IDs.
Of course, maybe the price of bitcoins will crater, rendering the whole process useless. Unfortunately, any alternative would have the same problem. You could have hidden tokens that you send to some web service, but then that service could stop running. You could have secret account details with a bank, but banks can fail. In a sense, this problem is the whole point: our knowledge should last longer than our institutions, and the fact that it doesn't at the moment is why you can perform this sort of creative value arbitrage.
