Issue driven development

A few weeks ago I tweeted the following:

I was requested to give a review about it:

This is basically the workflow I’m doing for issue driven development.

Issue driven development

What I mean with issue driven development is more feature driven development and is basically very straightforward:

Before programming anything, I first think about the feature and create an issue - hence its name. In the issue I put a description and all aspects I want to have.

I usually do this for multiple features at a time, so I create a bunch of issues.

Only then do I actually start programming anything. I pick the most-urgent or most-fun feature and start implementing it.

Mostly the most-fun feature, to be honest.

Milestones help me planning out when I do what.

The implementation

While I am using github to manage my projects, so I could file the issues there, I do not want them public.

This has a couple of reasons.

One is that then everybody could see how often I actually work on the projects and how long it sometimes takes me to get major features done.

Another is that while I describe the feature in detail I sometimes don’t actually think about the implementation too much. So I might plan features I can’t resonably implement. This means that I rarely need to close an issue without implementing it. If everybody can see all the planned features they might get very excited about something I end up not doing.

I don’t scrap the feature altogether, mostly I’ll just put it back and do another take on it later.

Public feature plans just put pressure on me I don’t want.

So I needed to host a private issue manager. After a twitter survey I went for Gogs. Gogs provides similar features as Github or Gitlab and looks very similar to Github but is written in Go. This means that it can easily run on my old Raspberry Pi instead of the full-blown alternatives.

The benefits

I’ve actually been doing Issue or Feature Driven Development forever.

But previously my issue storage was a mix of Google Keep notes, text on my whiteboard or on paper. Clearly, this approach was unmaintable. By switching to Gogs I organized it more.

Issue driven development gives me more structure. I have a clear plan of what to do and I can easily see how much progress I’ve made.

And it is always a nice feeling when you can close an issue.

The downsides

But of course the approach has some downsides.

Most notable on new projects: On standardese I have way too many internal issues, most of them representing some future features. I have the feeling that I spend more time with the issues than actually programming! The project is in such early development, there is near everything missing.

But the benefits are clearly superior: I have a clear plan on what to do.

Conclusion

This was a rather short and non-technical blog post. I just wanted to share the experience.

Also my next technical post would take some time and the daily views on the site were dropping. I also wanted to learn vim, so I needed to write some text.

Issue driven development isn’t something I’ve invented, it is an old practice. But it works really well.

This blog post was written for my old blog design and ported over. If there are any issues, please let me know.