Did you ever had that one great idea and always played with creating a mature open source project? And then started, diving right into it? And then just trying out this new feature of that API? And fiddling with the build process? And finally taking a break of all this stuff? And never come back to it?
In April I set out to write Milkman, an extensible postman replacement that allows me to finally have the features that I was always missing in Postman. In general, Postman and Milkman are applications that helps testing web APIs by sending/organizing requests. Milkman is a JavaFx application without many dependencies, having a smaller footprint than e.g. electron apps and is optimized for fast startup times. The code base now is about 12.5K code lines big, most of it was written in a time span of ~ 20 days in April, normally working around 4–5 hours per day. Since then, i spend about one day a week, 2–4 hours, fixing reported issues or adding new features.
Now, writing a large application like this without falling into the usual traps of losing motivation requires some things that I would like to write about today. I will not write about coding style or architectures that scale and allow your initial prototype to grow, this might be a topic for another day.
The biggest problem with open source projects is always motivation. How to keep up the motivation and don’t lose interest and stop? All the stuff mentioned below will help you keeping up your motivation and produce a mature (and hopefully open source) project.
Two thing that are important to keep your drive is Productivity (efficiency) and Focus (effectiveness).
Productivity
Being productive helps you spend time on what you actually want to work on, spend time on what makes fun instead of producing churn. It also helps you to create a lot of features within a small amount of time.
A commit a day / week
This is along the lines of Don’t Break The Chain and might be a well-known motivational technique. As I had some spare time in April, I could spend each day working on Milkman. Later on, I spend one day a week on continue developing and still can achieve a lot with that.
It was important to me to not skip a day, and if it is only to spend 30–60 Minutes, maybe adding some sentences to the readme and that is fine. Sometimes, I was not in the mood to work much, but as soon as I started, I wanted to finish that one feature and in the end, I spend 2–3 hours on this instead.
Planning that one day
As I only have that one day/week, I want to spend it as efficient as possible. Therefore I am planning the things I want to do on that day already earlier, maybe taking some notes during a train ride. That way, when I fire up my IDE on that one day, I am already ready to go and don’t have to think about what to do.
Also, I always planned my days by features. I wanted to finish this or that feature on that day. This also means that I had to kind of estimate, how long a feature will take and maybe split it into smaller ones.
A third thing I planned for those days was a prioritization of the list of features, I wanted to implement. Each day, there was a must-have feature set and a nice-to-have feature set. After finishing the must-haves, I was normally working already for ~3 hours. I could then decide to go on with the nice-to-have features or just stop there without any bad feelings. Most often, I picked one or two nice-to-haves as well.
Easy Release Process
I wanted to be able to spit out new releases/features in a blink of an eye, so I spend some time streamlining the build process so that it is not in my way. If I would have to always spend time doing tedious steps to release Milkman, this would be a barrier to even get started adding a new feature. Right now, I only have to type ‘mvn deploy’ and the whole application get packaged (containing a bundled JRE, an executable for windows etc) and uploaded to the GitHub release page automatically. I can go away and get a coffee meanwhile.
Also, I setup a CI that provides access to nightly builds, so people can even get development versions of the product.
Although, it is just one command, it still takes time and one day, I maybe further optimize it and put all handling of this into GitHub Actions, so that I can only trigger it once and can continue working on something else.
Minimal Tests
This one might be a bit controversial and I would never advise it (I always write lot of tests normally), but I have to be honest and this was one of the drivers for being productive. I did not test any obvious functionality. It is a desktop application and if something does not work, I will see it while using it. I did setup some tests, but they mainly test some of the more complicated stuff (postman collection import or garbage collector quirks in JavaFx).
This one might bite me later though. If I want to change things, I might accidentally break something without realizing it. I am still not sure, if the trade off is worth it, let’s see what the future brings. Up until now, I did not ran into many issues because of this.
Focus
Keeping my focus on the goal I wanted to achieve helped be staying effective and develop only what helps solving the problem. Because of the nature of applications, there is a lot of work to be done to finally see some minimum viable product (MVP). Iterating on this is then easier and you can see your progress making way better. To optimize that, the MVP should be as small as possible, so you can see results very early on and get motivated by the outcome and iterations (return of invest, so to say).
Clear Thread
When building the MVP for Milkman, I was solely concentrating on the clear thread. No design, no optimization, nothing that diverted me from contributing to the happy case use case of my application. The result was even less than an MVP but still a working application with persistence, a “usable” UI and something that executed requests.
No Sidetracking
One thing that was really important is to always reflect on the work that I was currently working on. Is it contributing to the feature that I am currently working on? Yes? good. No? Either stop it or at least timebox it (to 30 minutes/1 hour. This needs discipline) and drop it rigorously if it did not work out. I also needed to accept loose ends and non-perfect code. I needed to implement some hacks here and there to get things done. At some point later, when those hacks proofed to be an obstacle, they got removed. I could obviously spend all day refactoring the whole code base but this does not contribute to my current goal.
No Experiments
Normally, I start a hobby project with the goal of solving a problem but also learning something new (otherwise, it is called ‘work’ :D). Now, for this project, I avoided any experiment. I wanted to learn Kotlin or go, maybe look into graph databases or marry spring and JavaFx for a nicer development experience. No. The whole code base of Milkman is boring plain old java, nothing special. But that is what I am most productive in. I did not want to spend time finding solutions to problems introduced by my lack of knowledge about some technology.
Scope
Writing a replacement for Postman gives me a pretty good plan of what features I wanted to have but also what features I don’t want to implement. This helped me with defining the next features that I wanted to work on and leave out unnecessary stuff.
Additionally, I defined a set of general requirements before starting development, such as extensibility or fast startup time. All the features / code written was evaluated if it fits those requirements. I did this, again, to always produce stuff that contributes to some of the goals of Milkman.
No bugs
This does not mean to write code without bugs (especially, if there are not many tests), but I don’t accept discovered bugs to linger in my code (maybe with “FIXME” close by or a GitHub issue). If I would, they would pile up and rot my development experience. Nobody likes fixing bugs, but that’s why they are always in the must-have feature set planned for a day (see “Planning that one day”).
Sharing on Social Media
Finally, I would like to shortly talk about social media. Getting feedback is great, so you might want to use twitter or even twitch for live-coding to get feedback and also a pat on the back for your hard work, which is always a great feeling (GitHub stars, anyone? :D).
I chose not to because I think that this might lead to the wrong kind of motivation. I develop Milkman to solve my own need. I use it day-by-day and fix whatever issue I discover. Having people talk about it is a nice side-effect and I love for people to use Milkman, but that is not the reason for me to go on. It has to be a product that YOU use, but I guess, that is clear anyway.
