At first solo development in your spare time seems like it won't need as much planning or documentation as the work of a professional team does, and it indeed it doesn't. But the reality of a project run by a single developer in their spare time is that they lapse as interest and spare time wanes. It is a common programmer joke that even code you write yourself becomes unrecognizable, and so another interesting idea joins the folder(s) of incomplete projects (speaking from personal experience).
By making certain your own projects are properly planned and documented you can safely drop them and pick them up again weeks or even months later as time and attention permits.
But this is more easily said than done, so how do I plan to do this?
Docs as Code
While spending time on various subreddits and blogs (see upcoming blog post: Procrastination or Professional self development?) I've come across the idea 'Docs as Code' that seems to fit well with the goals I've set for myself. The central point is that the documentation is just as important as the code and should be handled with the same tools and included into issues and requirements.
To start this requires including documentation into the git depository, specifically as .md as github can display those properly. Secondly I will require features to be planned through documentation before starting coding.
The advantage of writing documentation ahead of time is that it forces you to think and design before writing, and just like coding to an interface it will make the documentation less determined by the code. The tool developed for defining and describing software is of course UML, and in the spirit of keeping code and documentation as close together as possible I'll be using PlantUML for this. While Github cannot render .puml files, with the right plug-in Rider can.
Solo Agile
When planning the project I need to be flexible and get quickly visible progress. As such I'll be using a variation on Agile. Instead of splitting sprints over time they will instead focus on a specific feature at a time. Hopefully regular results will keep my interest on the project.
If I'm going to use Agile that means I also need a big board and multi-colored post-its. Sadly keeping a bunch of those around at home for various active and less active projects seems unsustainable, so a computerized solution will have to be used. Github project boards are basically kanban boards that can be filled with issues and will allow planning and populating sprints while staying close to the code.
Even when working alone sprints and retrospectives should still be useful to evaluate the way I'm working and improve and expand upon the methods laid out here.
My goal with this blog is to become a better programmer, not just at writing code, but also at all the designing and planning needed to finish a project and deliver a program that can fulfill the requirements. I hope that by writing posts here to document and evaluate my methods and skills.
So for the next post in the Solo Experiment I will introduce the project I'm going to be working on and laying out its requirements.
Links
