Part 4 — Maintaining your GitHub Project

Paying down the planning level technical debt

What is technical debt?

Technical debt is the term used to describe the extra work that is created from low quality shortcuts taken to ship fast.

Typically we talk about software code as the only type of technical artifact, but really software is formalised knowledge, and knowledge artifacts can take on other forms such as a kanban itself.

Much like code, not dedicating enough time to maintain knowledge infrastructure (be it code or kanban), or simply not having the necessary skills to create quality knowledge (be it 'clean code' or 'clean kanban').

Over time, this debt can start to slow down development, as more and more time is spent working around the issues caused by the debt, rather than adding new features or fixing bugs.

A bug in software is easy to consider as you run software and encounter it in the form of a program crash. A bug in task organisation manifests as:

If not tackled, this can slow your iteration just as much as buggy code can, because you end up fiddling with the board rather than making progress. This is how you make bureaucracy for yourself.

Avoiding technical debt in your GitHub Projects

The same advice for code applies:

Kanbans are practical knowledge: if they're not being productive they're not working.

This post is part of Supporting and structuring personal development and open source contributions with GitHub Projects, a series covering how I began using the GitHub Projects tool for tracking my personal development and shipping outside of work. Read on for the conclusion