Motivation and Development Philosophy

This document describes the governing motivation and mentality for Forge development.


Computer graphics software is a complex domain with many working parts that are often tightly coupled (or just badly designed) for the sake of performance or to satisfy obscure edge cases. With Forge, our goal is to take a step back and challenge conventional computer graphics software design.

Developers who are keen to write high quality and experimental graphics software are more than welcome to contribute. It is an opportunity to entirely rethink the approaches made in existing solutions, and build novel ideas by returning to first principles. We try to keep the problem domain small, focusing on tackling a few problems well and carefully.

A minimal viable program is the smallest program that solves a particular problem. It is small and beautiful. It has no additional features.

If you removed a single feature it would be totally useless. If you added a new feature that feature would not be essential, you could use the program without making use of the new feature.

Minimum Viable Programs, Joe Armstrong

Designing components as beautiful, "minimum viable programs" is possible, it just demands some patience and forethought.

Best practices

Write clearly. Clarity here refers to elements of the program such as readability and control flow. Most of the code we write on a daily basis is really for other humans (including your future self) to read and maintain. The less time and cognitive load it takes for others to grok, the more time can be spent on actually hacking away.

This should not discourage the use of complex mathematics/algorithms or advanced language features where it makes sense, although it is helpful in these situations to include additional commentary to help less familiar/experienced developers. Comments are also instrumental on the occasion where readability is sacrificed for performance.

Assume other developers working on the project can read and understand most of the code. This means avoiding "fluff" comments. Name variables, methods, etc. clearly and your code will be naturally "self-documenting".

Exercise discipline. Satisfaction should not come from merely getting something to work, but from having it work elegantly. If it means spending more time on the task, then, by all means, take your time to iterate, revisit, and rewrite where necessary. Try to strike a balance, but prefer quality over speed. To reiterate, if something is a hack, then work on it until it is nothing short of simple and refined.

When working on a new component: aim to produce a minimum viable product that satisfies only the basic requirements of a solution. Keep it simple, ship it, then iterate on it with the benefit of hindsight. The severity of unaddressed niche or edge cases is often much clearer only after implementing and using version 0.1.0.

Use common sense to make decisions. The Code Style Guide intentionally avoids mention of formatting style, just stick to the style of the existing code. When in doubt, ask a maintainer or loosely refer to the Linux kernel coding style.

Unlike the suckless philosophy, frugality is a non-goal. Having fewer lines of code is ideal as it encourages re-use and simplicity, leaving less to maintain. On the other hand, it can often negatively affect clarity, which should be considered the primary motivation of Forge.