I’ve been enjoying coding a lot again lately, working on small little side projects like DNS Spy or open source tools like my recent adventures in Go. But since it’s just me and no one else, I have to prioritize certain features or tasks, which is where I found the concept of Release Notes Driven Development very interesting.
It’s a topic that came up on the latest Under the Radar podcast too, which is what prompted this blogpost.
Prioritizing as a single developer or small team
My code is riddled with technical debt. From the very first PHP tools I wrote a decade ago to recent open source projects like my Varnish configurations, each and every one of them has known flaws and known improvements, up for grabs.
The thing is, I know those flaws. I know those technical debts. I’m aware of them, can workaround them and can fit them inside my head when developing new features so I know how not to break old behaviour of my code.
Most of my code also doesn’t have unit tests for a similar reason. Not because I don’t see the value in them, but because I can’t prioritize them in good conscience.
Why? Because they make for lousy release notes.
The thing is: if I have a couple of hours to spare and work on my projects, I want something meaningful to come out of those hours. I want something to brag about on Twitter. To show to my users. To add a feature that’s been in high demand.
Release notes that matter
Here’s what most release notes end up reading;
- Performance fixes and improvements
- Minor bugfixes
- Less crashes than before
I’m sure your users benefit from that, but here’s a set of release notes that are worth a lot more.
- Added support for feature X
- Added new layout for Y
- Improved readability and rendering on Z
The difference? Those are tangible, real, improvements for your users. Things users look forward to.
Sure, less crashes is good too. Sure, minor bugfixes are too. But that’s what you expect from every release. Software should increase in quality.
What makes an actual difference? Adding features, extending functionality and solving user problems.
Write release notes first
What I try to do for my projects is come up with the release notes first. I might not call them release notes, per sé, but a list of “braggable features” to showcase. Every line of code I write from then on is to make that goal happen as efficiently as possible, without sacrificing existing functionality or stability.
The latest DNS Spy releases improved CAA scanning functionality, bugfixed several issues related to dynamic TTLs and fixed several rendering bugs where domains would show up as out-of-sync.
What I didn’t do? Rewrite core parts of my app (even though in some parts, that would be needed, as I’m learning more about the Laravel framework and the shortcuts it offers), add unit tests or rewrite parts of the framework.
Should I? Yes, in due time, but they make for lousy release notes and right now, that’s not a luxury I can afford.