Last December in Vienna, at a workshop on the future of the Figl Observatory, I put up a slide with two columns. On the left: scientific software. On the right: industry-grade software. Between them, a small “vs” that I have come to regret slightly — it is not a fight, and it is not a hierarchy. But the two columns are real, and the distance between them is much larger than most people in astronomy suspect.
Two ways of being good at this
Scientific software is result-oriented. What matters is the number at the end, the plot, and ultimately the paper. The code is the path to it, and once the path has been walked, its condition matters less than the fact that it led somewhere. The focus is on the programming itself — on the content, the algorithm, the model. Automation, when it exists, is often a shell script that someone wrote once and everybody now runs with their fingers crossed. The output is typically self-contained: a program, sometimes a library.
Industry-grade software is process-oriented. What matters is not that the software works today, on this machine, in the hands of the person who wrote it. What matters is that it will work in eleven months, on a machine nobody has bought yet, in the hands of someone who has never met the author. So you build systems rather than programs, you expose APIs rather than command lines, and you become — there is no polite word for it — obsessed with automation. Tests at every level, from the unit to the subsystem. Scans for security and licences. Scans for bugs, code smells, reliability, maintainability. Builds, packaging, versioning. Delivery and deployment. Scaling, monitoring, logging. API documentation that is generated, not written and then quietly abandoned.
The word “quality” means different things on either side. On the left it means the result is correct. On the right it means the result is correct, and will still be correct after the next twenty changes, and we can prove it in four minutes without a human touching a keyboard.
The continuum, and its honest inhabitants
Of course it is a continuum. Astropy and NumPy sit far along the industrial side while being unmistakably scientific in origin — but they are libraries, not products, and a library carries a fraction of the obligations a product carries. AladinLite lives somewhere in the middle and is all the more interesting for it. Most observatory control software lives further left than its operators would like to admit, and a few instrument teams run a discipline that would embarrass a fair number of software companies.
Each side pays for what it gets. The scientific side buys speed, freedom, and the ability to change its mind on Tuesday about what it believed on Monday — and pays in fragility, in knowledge that lives in one person’s head, in the six weeks a new postdoc spends re-deriving what the previous one knew. The industrial side buys durability, reproducibility, and the ability to hand the thing to a stranger — and pays in overhead, in a slower first version, in the discipline of writing the test before the feature. A one-off analysis wrapped in a CI pipeline is a waste of a life. An observatory that must run unattended for a decade, built like a one-off analysis, is a different kind of waste.
The question is never which side is better. It is which side the problem is on.
Where Arcsecond sits
Arcsecond is on the industrial side, deliberately and without ambiguity. It is a multi-gear, multi-telescope platform that automates astronomical observatories — which is to say it is asked to work at three in the morning, in a dome nobody is standing in, on a night nobody wants to lose, for years. There is no version of that job that a result-oriented codebase can hold. Every line of the right-hand column is not a preference; it is the entry ticket.
This is the part that is easy to underestimate from the left-hand side. The gap is not a matter of effort or of intelligence — the astronomers I have worked with are not short of either. It is a matter of a body of practice that simply is not taught during a PhD, and that takes years to acquire, because most of it is only learned by being responsible for software that other people depend on, over a long enough period that your own past decisions come back for you.
I know the distance between the two columns because I walked it slowly. Astrophysics PhD in 2003, then years as an astronomer, including four at ESO in Chile — where I learned what an observatory actually costs when something does not work. Then, from 2010, fifteen years in industry: developer, then tech lead, then software director, in a field where a defect does not cost you a night of seeing but a production line. That second half is where the right-hand column was beaten into me. Arcsecond is what happens when you point that discipline back at the first half.
“We do it ourselves”
That is the sentence I hear most often in observatories, and it is rarely wrong as a statement of capability. It is usually wrong as a statement of schedule. Because alongside it, in almost every dome, there is a list: the upgrade started three years ago, the new mount that was going to be integrated properly, the archive that was going to replace the folder of folders, the scheduler that exists as a prototype somebody defends at coffee. None of it is beyond the team. All of it is beyond the team while also operating a telescope.
What I have seen is that adopting Arcsecond tends to be the moment those lists finally close. Not because the platform does everything — it does not, and it does not want to. But it is the last mile, and the last mile is precisely the part that is never anybody’s thesis. It is what stands between a set of working parts and consistent, reliable, efficient observing. Once there is a deadline attached to something that will actually go into production, the half-finished upgrades stop being background guilt and become work packages with an end.
(I’ll write a dedicated post on that subject).
What I would say to a team writing their own
Not “stop”. Scientific code is how science gets done, and the instinct to build the thing yourself is a good one. But be honest about which column your software is in, and about which column the job requires — because the mismatch is where observatories quietly lose nights, and it never announces itself as a software problem. It announces itself as a bad run, a lost target, a student who left.
And if the job is on the right, understand what you are signing up for. It is a completely different mindset, made for delivering consistent results over the years. That is the whole sentence at the bottom of that Vienna slide, and it is the only part of it I would not change.
No responses yet