Developer Story: The Astronomy Software Planetensuche

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 domain knowledge and features. Whether it's a private project, open-source, or commercial—nobody knows on day one which features will ultimately bring the breakthrough that makes users actually want the software. Building software right out of the gate that could win first prize for Clean Code and test coverage doesn't help. If nobody needs the software, the project is dead sooner or later anyway. Plus, so much can change early on that 100% test coverage and documentation would actually be a hindrance. All those tests and docs have to be adjusted every single time, which is time-consuming and keeps you from developing a new feature. The real challenge is shifting the software development toward a long-term focus after you've developed your USP. This means that instead of constantly rebuilding, you move to continuous refactoring. High test coverage and documentation suddenly provide real added value. The architecture also has to shift toward maintainability and reliability. Maximum flexibility is no longer as critical. For Planetensuche, minor or major refactorings are part of every release.

2. Clean Code Matters
At the start of a new project, it's tempting to think, "Clean code isn't that important; after all, I wrote every class myself and know my way around." However, if a project succeeds and years go by, the forgetting sets in. Planetensuche now has over 172k LoC (in more than 1,900 Java classes), and even though I wrote every single one of them, I certainly don't remember them all. Design patterns are extremely important to help you navigate the codebase even after years of forgetting. And to ensure that reading and extending the code remains fun, clean code is simply worth its weight in gold. Naturally, this also requires the courage to regularly refactor old code. Unfortunately, this courage isn't a given among software developers. Some open-source projects have essentially been allowed to accumulate cruft over the years, scaring off potential contributors. In Planetensuche, I use Checkstyle and PMD to get feedback on potential issues right during the Maven build. The enabled compiler warnings are also quite helpful. I used to run SonarQube as well. But unfortunately, the configuration became unreadable after every upgrade, and setting it up from scratch was very time-consuming. I eventually buried the SonarQube topic entirely. That is, unfortunately, a prime example of bad software. Administrative overhead should be low; otherwise, it hinders adoption.

3. Modularization Helps
As mentioned, Planetensuche is modularized. There are currently 21 Maven modules. Since I modularized Planetensuche before it was officially introduced in Java 9, I basically have my own custom module system. Roughly divided, there are utility modules containing utils and other base classes, and GUI modules containing frontend and backend classes (MVC). For example, the program sections "Database Module" and "Star Map" (opened via the UI) are two distinct GUI modules. Every module has a clear functional or technical purpose. While classes in the utility modules can (and should) be called from anywhere, the GUI modules have clear interfaces to launch them. Modularization is highly useful because it means I don't have to rebuild everything during development (which would take a very long time given the many tests). Planetensuche is essentially a deployment monolith (internally many small functional units that are ultimately packaged into one big, fat JAR file). For a desktop application, it makes a lot more sense to output a single artifact that users can run. I can only recommend *not* building true monoliths nowadays. If a project becomes successful, untangling a monolith is enormously time-consuming. So it's better to build small, cleanly separated functional units right from the start (i.e., build modular deployment monoliths at most).

4. Internationalization Brings Reach
To achieve broader adoption, offering software in English (GUI, changelog, documentation, homepage, etc.) is a good idea. Given the global population distribution and language demographics today, adding Hindi and Mandarin would probably be smart, too. Thanks to the internet, you are potentially connected to everyone. Once, a user from Asunción in Paraguay wrote to me. When I was developing Planetensuche, it never crossed my mind that I would have users that far away. How exciting! Moreover, thanks to AI, you no longer need to speak English, Mandarin, or whatever fluently yourself. As long as the UI strings are cleanly separated from the code, the software can be easily translated. That is the case in Planetensuche.

5. The AI Era
Since I just mentioned AI... It's still unclear where AI will ultimately take us. At the moment, AI is a magnificent productivity tool. Software projects run as a "one-man show" like Planetensuche profit enormously. It feels like I've hired four employees to generate new ideas, refactor old code, and build new features. I even had an extreme case where I wanted to build a feature 20 years ago, but there was a bug somewhere. Only with Gemini was I able to find the calculation error and ship the feature in version 6.31. Even tedious tasks like converting Java 6 code to Java 21 are quickly handled by AI. And, at least in the non-commercial realm, you still have the choice to write the code yourself (and have the AI review it). Now that AI handles the programming work, it is becoming increasingly important for software developers to focus on domain knowledge and software architecture. Finding a good and fitting architecture requires a certain degree of perseverance, just to stick around long enough to witness the consequences of your design decisions. At work, I constantly meet developers who (for various reasons) only spend 1-2 years at a company. During such brief "visits," you neither get to know the projects properly (i.e., domain knowledge remains superficial), nor do you experience the fallout of the design choices you made. But this removes a crucial learning instrument: feedback. This is where it becomes clear who is actually gaining real professional experience and who is merely accumulating years of service. Planetensuche has a long history of design decisions, some good, some bad. Experience is priceless.

6. The Value of a Backlog
I can't remember which book it was where I read the tip to write down ideas immediately. Either way, the tip was worth its weight in gold. I use MantisBT for Planetensuche. While it's primarily a bug tracker, it works quite well for capturing new features and improvements. I have written down every single idea I've had for the program. In the end, I was amazed at how many ideas have come to me over the years. Even after 23 years of development, roughly 30% of the features are still open (because new ones are constantly added).

7. Meaningful Testing
This is the most controversial topic among software developers. Personally, I don't believe in 100% test coverage via unit tests. Tests should be meaningful and provide added value, regardless of what the textbooks used to say about the test pyramid. Planetensuche has many classes and methods that calculate things or map data from one DTO to another. These classes are perfect for unit tests, and they make sense there. Occasionally, though, you have classes and methods that are simply unsuitable for it, e.g., because they only call other classes and do nothing else. Professionally, I've seen a lot of terrible unit tests that essentially just test whether Mockito is working properly. If you then refactor the code, these tests are either all green even though the method returns a wrong result, or they all turn red because they expect a specific behavior from the method, even if the method's final output is still exactly the same. In Planetensuche, I skipped such useless tests. Test coverage is highest in the utility modules and decreases in the GUI modules (since there are no click tests). For methods that only call other classes, there are only integration tests, so I can see immediately if the code still works. Especially with external dependencies, you have no control over the interface's behavior, so integration/system tests provide the necessary visibility there. In some places, there are also performance tests. Maven executes these tests after all the others per module, as they take the longest.

8. Java is Old and Java Apps are Bloated
When thinking of Java, some people picture an old, cumbersome programming language (due to lots of boilerplate code) used to build heavyweight web applications. In my experience, this isn't true, or at least it doesn't have to be. Recently, there have been several projects to introduce new language features into Java. Today, you have to write significantly less code (e.g., using `record` instead of POJOs with getters & setters), and Java is constantly improving. The JDK now includes numerous features that previously required external libs like commons-io, commons-lang3, Guava, Joda-Time, etc. And now that AI generates the code, it perhaps matters less whether a language is strictly minimalist (minimalism often hurts readability anyway). The other point about bloated applications depends on the context. You can build small, lean programs with Java, too. Planetensuche relies on lightweight libs for core topics like dependency injection (Guice instead of Spring) and ORM (Querydsl instead of Hibernate). The fact that Planetensuche has nonetheless become quite memory-hungry over time is solely because it uses the in-memory database HSQLDB, and the database has grown over the years. It is absolutely possible to build and run a resource-efficient application (the JVM offers numerous optimization parameters, and you can squeeze out a lot, especially for server applications).

9. Domain Model and Validation
Planetensuche imports data from a wide variety of sources. All this data must be validated to ensure the numerous charts and other program features work correctly. I use a two-stage strategy here: First, source-specific validations happen right during the import (e.g., checking if object names and catalog numbers are correct). Then, right before the data is saved, a fundamental validation checks for sensible value ranges per object property (e.g., the mass of an object cannot be negative). Data is not persisted directly via the entity classes (in my case, the generated Querydsl classes), but through a domain object. This domain object handles the validation of all data. For reading data, on the other hand, the entity classes or a POJO variant of the domain object can be used directly. This guarantees that no garbage data ends up in the database, while keeping read operations (which occur much more frequently) fast. It also keeps the business logic strictly separated from the database layer, which should make a future refactoring from Querydsl to jOOQ or something similar much easier.

"Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program."
– Linus Torvalds

last updated on May 25, 2026