Planetensuche

Planetensuche / die Jagd nach Exoplaneten

Home<br>Planetensuche<br>Projekte<br>Kontakt<br>Disclaimer

Developer Story: The Astronomy Software Planetensuche

How a QuickBasic program for finding a second Earth evolved into a 172k LoC Java project over 23 years—and what I learned about architecture, AI, and refactoring.

When I read an article titled "The Search for a Second Earth" in the science magazine "bild der wissenschaft" in May 2000, I got absolutely hooked on the topic of exoplanets. It hasn't let me go since. The idea that there could be another planet like Earth in our Milky Way (possibly even harboring life) simply fascinated me. Back then, it was pure sci-fi. There were just over 30 known exoplanets (as of May 2026, we are at almost 6,300), and most of them were massive gas giants orbiting very close to their stars. Anything but a second Earth. Today, the data looks far more promising.

In the summer of 2002, I started learning my first programming language, QuickBasic. I had the idea to develop something long-lasting to truly learn how to code. That’s how Planetensuche (Planet Search) was born. I wanted a program that I could "feed" with the raw data of discovered exoplanets. Based on that, a probability calculation using a checklist would estimate whether life could be possible on one of those planets. The data available at the time wasn't sufficient to make a real statement. Nevertheless, that was the first feature in Planetensuche. To this day, I know of no comparable software dedicated to exoplanets and exobiology.

In late 2002, I switched to VisualBasic and completely rewrote Planetensuche (Version 2.0). This made clickable GUIs possible, which was much more appealing than DOS prompts. Version 3.0 included a major refactoring but otherwise stuck with the same technology.

During my Computer Science studies (2004-2008), I got to know numerous new programming languages and decided to rewrite Planetensuche in Java 5 by the end of 2007 (Version 4.0). With this rewrite, Planetensuche was modularized (as a Maven multi-module project), an architecture that has survived to this day (more on that later). The NetBeans GUI editor was incredibly helpful, allowing me to quickly finish the frontend in Swing (and partly AWT). With version 4.1, it also became possible to highlight all stars with known exoplanets on the star map. This feature was later added to Stellarium, following my example.

Version 5.0 in mid-2013 came about due to the introduction of Querydsl. On the one hand, it replaced "magic strings" in the source code, helped write SQL, and ensured type safety. Querydsl is still in use today and serves as a highly useful, lean persistence layer (Planetensuche doesn't use Hibernate or similar). Unfortunately, it seems the Querydsl project has gone dormant. A major refactoring to jOOQ or something similar is probably looming on the horizon... Another change was introduced here: versioning moved away from strict semantic versioning ("Major.Minor.Bugfix") to two-part versioning. This significantly simplified the whole release and versioning process.

Version 6.0 in early 2020 brought a bigger leap from Java 8 to 11. Due to the JDK's new release policy, I decided to stick to LTS versions. Future Planetensuche versions didn't get a major version bump just because of the Java version. Thus, in mid-2023, version 6.22 was followed by 6.23, despite the upgrade from Java 11 to 17. And in 2025, the migration to Java 21 also didn't trigger a major version change (Version 6.29).

Even small software projects can no longer escape the AI hype. Version 6.31 (released March 15, 2026) was the very first version developed with the help of AI (Gemini 3.1). Since I am a solo developer, execution sometimes suffers from a lack of code review. Thanks to Gemini, I now have the option to either have my code reviewed or, conversely, to review the generated code. Gemini was enormously helpful in refactoring old code (e.g., updating very old classes to Java 21 or migrating from JUnit 4 to 5). Thanks to the massive knowledge base Gemini has acquired, I can quickly find solutions to problems that would have otherwise taken hours of research. Even tedious tasks like translating the changelog can be done super fast with AI. The speed you can achieve alongside AI is enormous. I would say I am about 4 times faster than in the pre-AI era. This works great here, of course, because I don't have to coordinate with anyone else. At my day job, the reality is much more sobering; the actual programming part of my total working hours is rather limited, which makes the advantage of AI much smaller.

What can we learn from this?

1. Rewriting vs. Continuous Refactoring

Planetensuche has been around for over 23 years. As described earlier, there were a few points where the software was completely rewritten (each time in a new programming language). I think at the beginning of a new software project, it's crucial to focus on building...