Hobby Project

Declaring a hobby project

Before doing anything else, you should everybody looking at your project know that you work on it as a hobby. This helps you set the correct expectations. You can use this MarkDown snippet in your README.md file:

> **Hobby Project**
>
> This is a [hobby project](https://hobby-project.dev). It is worked on recreationally, and its
> resources are limited. This may impact you. Follow the previous link to learn more.

Keeping things managable

Staying in control of your hobby project, not getting side-tracked and not letting it overwhelm you, is quite hard. Companies often employ project managers who do it professionally. For a hobby project, hiring people is unfeasible, and without doing so most usual approaches are to time consuming.

Setting clear goals

Feature creep is very dangerous to hobby projects. They usually run on minimal resources, and in that situation adding a couple of features here and there can be the difference between a success and another abandoned idea.

As a counter measure you should set explicit and specific goals from the very start. All features that are not strictly necessary to achieve these goals are implicitly out of scope.

This also applies to logical or trivial extensions. If you really want to, you can tackle them once the core project is complete. Until then, leave them be.

Choosing dependencies

Most modern programming languages have a way of easily importing dependencies. This is great, because it allows you to quickly implement your actual project, instead of having to build a lot of needed infrastructure first.

However, dependencies are not free. They add complexity to your build process, can be confusing during debugging and may be the source of security issues.

They also will receive updates (hopefully). Migrating your code to new versions can quickly become a nightmare, once fundamental dependencies have major changes, or different libraries start fighting each other because of version mismatches.

This gets especially bad, if you don't update somewhat regularly. That however can be a problem in itself for hobby projects, which can have months-long pauses for variety of reasons.

As a mitigation, you should carefully consider the pros and cons of each dependency you add. Is it really worth it, or could you implement the same rather quickly. You should also check the history and policy of dependencies, and prefer stable, predictable ones.

Preparing for long pauses

Life is busy, and hobby projects are usually not that high on your list of priorities. This means that there can be long pauses between bursts of activity. In that downtime, you'll forget important knowledge about your own project. This is not only frustrating, but can also lead to severe bugs. So you should prepare for it.

Extensive documentation

Few things in software development are as frustrating as having to understand what you were thinking a couple of months ago. Aside from being annoying, this is also time consuming and hard. So you should put in some effort upfront and document everything.

For a hobby project it is best to keep the documentation close to the actual project. If you document a piece of code, use doc comments if your language supports it. For other, more abstract information, create a docs folder and fill it with markdown files. This ensures that you don't loose the documentation itself.

You should write down at least the following information:

1. The project goals
2. How to build and run the program
3. The overall architecture
4. A list of ToDos and their current status
5. The purpose, usage and expectations of your data types and functions. Use doc comments if possible, so that a language server can show this to you as a tooltip.

Automated testing

A common source of bugs is one function using another, with both of them disagreeing what it should do. For example, a data loading function might think its caller is responsible for closing the database connection, while the caller thinks the function should do it.

Such mismatched expectations of behaviour can easily occur when significant time passes between writing the two functions, or when changing one several months later. Even the best documentation won't save you from making this mistake.

The only thing you can do to prevent such bugs is writing automated tests, and running them before each commit/version. You should make use of unit and integration tests, and aim to cover as much of your code as possible.

While this will greatly reduce the number of bugs you create, it likely won't be sufficient to reach 0. But even so, most bugs are easier to find if you already have a couple of example cases, which you can compare with each other.

When you do fix a bug that got through your tests, remember to write additional ones which would catch it. This is important to prevent regressions. Also document what that test protects against. You can do this with comments, ideally doc comments.

Simple development environment

Some languages provide development environments that are time consuming or complex to set up. Examples of this are Visual Studio for C# and RAD Studio for Delphi. These often contain a lot of helpful tools for active development.

The problem is in the time they take to set up. If, for any reason, you need to move to a new computer, this might be the end of your project. You might think thins to be an exaggeration, but it is not. It is easy to fall into the trap of doing something else and saying you'll install it tomorrow.

Depending on your language you can avoid this by using a simplified, quickly set up development environment. For example, re-preparing Rust (with rustup), Helix and Git (with SSH keys for authentication and signing) can easily be done in ten minutes.

Enduring abandonment

Sooner or later you will stop working on your project, because you loose either the will or ability to do so. Depending on what your project is about, or who you are making it for, you might want it to endure that event, at least for a little while.

Targeting an stable platform

One of the most frustrating ways that software can become inaccessible to its users is for the platform it runs on to either be abandoned itself, or receiving an update that contains incompatible changes. Neither you, nor the user, nor necessarily the platform developer did anything wrong, but suddenly your project is gone.

Some projects only can be done on one specific platform, and for those this problem is unavoidable. For example, the stability of the Linux kernel means absolutely nothing to a mod for Cities: Skylines 2.

For others, however, you do get to choose. For example, you might prefer shipping your project as a docker container over shipping it as a normal binary, because that way you can bundle in the exact versions of your platform dependencies.

A good bet, as far as stability is concerned, is the web, specifically Baseline widely available . If you can use it, this is probably your best bet, because it is well documented, standardised and multiple independent implementations exist. That last point is something, that almost no other platform can claim.

Minimising upkeep costs

If your project needs centralised resources to work, that you have to supply yourself, this will often come with some kind of upkeep cost for you. For example, a main server running in a rented VM might cost you 5€/month.

If you want your project to endure, you should strive to minimise these costs. The lighter the burden on your wallet, the less pressure you'll feel to get rid of it. Also, this makes it easier for a potential successor to keep it available.

If the central resource is a static website, you should consider offloading that to a free host that probably will outlast you. You could consider Codeberg Pages for this, or GitHub Pages.

Consider open source

If you open source your project, with a permissive license, somebody someday might come along and pick your project back up. Maybe they'll keep it going for a longer time, and everybody gets to enjoy it.