I have rarely lacked ideas. If anything, the opposite has been true.
One original idea would lead to another feature. That feature required new logic, additional artwork or a technical foundation that had not been part of the initial plan. During development, further possibilities appeared that could genuinely improve the project. In this way, a manageable undertaking gradually became something that was difficult to complete within the time available.
This is not an unusual development. Especially in programming, it is easy to include the next interesting idea as well. A new feature often seems harmless when considered on its own. It still has to be developed, integrated into the existing structure, tested and maintained later. When enough such additions accumulate, they change not only the scope, but sometimes the entire project.
There is also the fact that not every problem can be solved with knowledge one already has. Sometimes a feature requires a new technology, an unfamiliar framework or a subject that first needs to be studied properly. The required knowledge may be available in principle, but there is not always enough time or inclination to spend weeks searching through documentation, forums and tutorials before the actual work can continue.
A project does not necessarily come to a halt because of one major obstacle. More often, it is the accumulation of many small additions and unanswered questions.
Small Does Not Mean Simple
When I speak of small projects, I do not mean hastily produced programs with as few features as possible.
A small project can be technically demanding. It may consist of several components, connect different systems and require careful design. What matters is not merely the number of files or applications involved, but whether the undertaking as a whole remains understandable, manageable and capable of being completed.
The boundary of a project is not always easy to define either.
A separate API may technically be its own application and still belong directly to the project if the main program cannot function as intended without it. A service that processes images or provides data may be independently executable, yet still form part of the same overall solution.
For that reason, I do not find general rules such as “This feature no longer belongs to the project” particularly useful. A better question is whether a new idea still serves the original objective and whether its benefit justifies the additional effort.
That cannot always be answered with certainty in advance.
The Difficulty of Leaving Things Out
Having further ideas after the planning stage is not inherently a problem. Planning cannot anticipate every useful thought that may arise later. Some features only reveal themselves as necessary or worthwhile during development.
It becomes a problem when every good idea is treated as something that must also be implemented.
As a developer, I sometimes find it difficult to omit a feature that I believe could improve the result. The technical possibility exists, the benefit seems reasonable and the implementation would be interesting. Even so, it may exceed the intended scope.
This is a common programmer’s affliction: because something is possible and appealing, it should preferably become part of the project as well.
The real decision is therefore not whether the feature is good or bad. It may be a good feature and still need to be left out for the time being.
A deliberately limited scope does not mean that no further ideas are allowed. They simply have to be weighed against the original objective, the expected effort and the available time. Some can be reserved for a later version. Others may provide the basis for an independent project of their own.
Leaving something out is not a sign of technical inability. It is a decision about priorities.
What “Finished” Means to Me
A program is not finished simply because no further ideas exist. That point would probably never arrive.
Nor does “finished” mean that no errors remain. Any sufficiently complex piece of software may contain unknown defects. “Complete” is also of limited use as a general term, since another feature could almost always be added.
For me, a project is finished when it is functionally complete according to its originally defined requirements, has been tested and contains as few known errors as reasonably possible.
The original definition matters. Without it, the target keeps shifting throughout development. Every new idea becomes an allegedly missing feature, and the project can never reach an end point.
Requirements may, of course, be corrected during the work. Sometimes implementation reveals that an assumption was wrong or that a feature needs a different structure. Such a change should be a deliberate decision, however, rather than the automatic result of every new possibility that appears.
“Finished” is therefore not a claim of theoretical perfection. It describes a comprehensible state in which the project fulfils its defined purpose and can be published or put into use.
Publication Is Not the End of All Work
A completed project does not have to remain unchanged forever.
Maintenance is part of development for me. Some errors only become visible after publication. Operating systems, dependencies and external services change. Adjustments may be necessary to keep a program working.
Useful extensions are not ruled out either.
The difference is that the existing project has already reached a functionally complete state. Further work builds on that foundation instead of prolonging an endless first development phase.
Not every program needs to keep growing indefinitely. Some projects require regular maintenance, while others need only occasional corrections. A project may also remain unchanged for a long time if it continues to serve its purpose.
The Scope Must Match the Available Time
I do not work on my personal projects every day or according to a fixed schedule. For that reason, I do not measure their size solely in weeks or months.
A project may take several months. What matters is whether visible progress remains possible during that time and whether the goal still appears realistic.
If a private project has still not reached a functional conclusion after several years, however, the concept should probably be reconsidered. The scope may have become too large. The technical foundations may have changed, or the original structure may now make further work unnecessarily difficult.
In such a case, starting again may be more sensible than trying to preserve every old decision.
That does not necessarily mean discarding all previous work. Knowledge, content and individual components may still be reused. A revised concept can provide an opportunity to make the actual core of the project visible again.
Appreciating Large Projects Without Trying to Reproduce Them
Large games and applications can be impressive achievements.
Major double-A and triple-A games are created by large numbers of people working over several years on programming, artwork, animation, sound, design, writing, testing and many other areas. I greatly respect the amount of work involved.
That is precisely why I would not begin a comparable project myself.
The scope of such productions cannot realistically be transferred to one person working in her spare time. The attempt would not result in a smaller version of the same achievement. It would most likely result in a permanently unfinished project.
My own work does not need to compete with large productions. It can pursue a smaller purpose, examine a single idea or place one particular game mechanic and atmosphere at the centre.
A limited project can still be developed with care. Its quality does not depend on how many features, hours of play or interconnected systems it contains.
Independent, but Not Without Support
Independent development does not mean that I must complete every task without external knowledge or tools.
I use libraries, development tools, documentation and, by now, generative models as well. When necessary, I rely on existing solutions or ask for unfamiliar approaches to be explained.
A project remains independent because I define its objective, make the technical and visual decisions and take responsibility for the result.
Support can prevent a lack of specialist knowledge from bringing an entire undertaking to a halt. It does not remove the need for me to judge whether a proposed solution actually fits the project.
For an individual developer, this combination of personal decision-making and available support can make the difference between an idea that was merely started and a project that was actually completed.
A Manageable Objective
Jessa Studio is intended to provide space for games, applications and experiments without requiring each of them to become a long-term major project.
I want to develop projects whose scope matches the time available to me. They may be technically demanding, consist of several components and change during development. They still need a recognisable objective and a point at which their original purpose has been fulfilled.
My current project follows the same approach. Further ideas and possible extensions are already appearing during development. The work therefore consists not only of implementing them, but also of deciding which ones are genuinely necessary for the first complete version.
Note: This article was also created with the support of a language model. The content, positions and examples are my own. The model assisted with structure, wording and stylistic revision.
Conversation
0 comments
Comments are reviewed before publication. Be constructive and stay on topic.