Every observatory I visit has one. Sometimes three.
It has a name, usually with a version number in it. It was scoped in a meeting whose notes still exist. Someone very capable started it — often the best person on the team, which is part of the problem. There is a branch, or a directory, or a machine in the rack that everybody steps around. Ask about it and you will get a slightly weary smile and a sentence that begins with “yes, so, that one —”.
It is not abandoned. That is the strange part. It is nearly there. It has been nearly there for two years.
Why it stalls
Upgrades in observatories stall not for lack of skill. Observatory teams are full of people who could write the missing piece, and often already have, twice, in a prototype nobody dares delete.
It stalls because of what an upgrade is, structurally. It starts when the pain is loud — the mount that needs babysitting, the archive that is a folder of folders, the scheduling done by a human at 2 a.m. And it stops when the pain drops below the threshold of the next louder thing. Eighty percent of an upgrade removes ninety percent of the pain. The remaining twenty percent is the part with no glory in it: the error paths, the second telescope, the case where the dome does not answer, the documentation, the handover. Nobody’s thesis is in there. No proposal was funded for it. The instrument works “well enough”, and the sky is clear tonight!
Then there is the ownership question, which nobody likes to ask out loud. Whose job is it? The engineer who started it has moved to the new instrument. The PhD student who wrote the scheduler graduated. The knowledge did not vanish, exactly — it is in a notebook, in a README, in the head of someone who now answers emails from a different institute. Restarting costs more than continuing, so it is not restarted, so it costs more still.
And underneath both: there is no date. Nothing external forces the last twenty percent to be finished. An upgrade with no production date is not a project; and usually nobody wants to be or hire a project manager.
What “we do it ourselves” really means
The team can do it. I have never doubted that.
But “we do it ourselves” is answering a question about capability, when the question actually on the table is one about capacity and finish. Can you build it? Yes. Can you build it, harden it, document it, keep it running for a decade, and survive three staff changes — while also operating a telescope every clear night? That is a different question, and it is the one the unfinished upgrade is quietly answering, in the negative, every year it stays unfinished.
There is also a hidden cost that never appears in any budget line, because it never announces itself as a software problem. It announces itself as a lost night, a target that drifted, a calibration redone, a student who spent six weeks rediscovering what the last one knew. Sum those over five years and compare them to what the upgrade was estimated at. The comparison is never made, because the two numbers live in different worlds.
That’s perfectly understandable, and lots of observatories struggle.
The deadline is the deliverable
What I have recently seen is that adopting Arcsecond is the moment the lists finally close.
Not because the platform does everything — it does not, and does not try to. Arcsecond is the last mile: the layer that turns a set of working parts into consistent, reliable, efficient observing, and keeps it that way when nobody is in the dome. It sits on top of what the team has built, not instead of it.
But being the last mile has an effect that is almost sociological. Something is now going into production, on a date, in front of the whole observatory. Suddenly the second telescope has to be integrated properly, not “supported in principle”. The archive has to be readable by a machine, not by the person who named the folders. The error paths have to exist because something will call them at three in the morning. The half-finished upgrades stop being background guilt and become work packages with an end and an owner.
Teams often tell me afterwards that the platform was the smaller part of what changed. What changed was that a set of things everyone knew needed doing finally had a reason to be done this quarter rather than next.
If you recognise your observatory in this
At that point you have three honest options: give it a real owner and a real date and defend both against the sky; decide out loud that it is cancelled, and stop paying for it in lost nights; or attach it to something with a production date, and let that pull the last twenty percent over the line.
The one option that is not available, though it is the most popular, is to keep it on the list.
No responses yet