Because Mendeley was invited to the New Horizons flyover in Washington D.C. I was reflecting a bit more on probes and sending things to the space from the software engineering point of view.
Be aware that I have no much knowledge about space probes, computers in the space, their development methods, etc.
One of the things that I thought is how I would feel if today I wrote code that would only really be used in real (production) 9 years later. Or design a hardware system that would be sent, out of my control (for sure the hardware, maybe not the software) out in the space for 9 years and then it really must work.
In Mendeley (and many other companies) there are different release methods. I would say divide them like:
- Web/Platform code: a re-deployment should take minutes. Someone could fix a bug and release easily to all the users
- Desktop (like a Windows, Mac, Linux application): a release can be done but the users must update their applications! The update process can be easy for the user, but we have to think that some users can’t update quickly (for example institutional computers), some users might not accept updates, etc.
- Mobile apps: after fixing the problem they need to send the app to the store (PlayStore, etc.) and get the app approved again by a third party application. And then they still must handle that some usres might not update everything at once.
For the New Horizons probe: there is only one opportunity for the software to work when it’s flying close to Pluto. Only once, can’t fail! I’m sure that they tested many times, simulated, code reviewed, triple reviewed, unit tested, etc. but still nothing can go wrong at that time or the opportunity is over. In my case I tried our best to not have bugs but if something happens we know that we don’t need to send another probe and wait for 9 years (or even more!) to take the second chance.
Leave a Reply