104 lines
6.8 KiB
Markdown
104 lines
6.8 KiB
Markdown
|
# todo trees: project management for prototypes
|
||
|
|
|
||
|
|
!! If you're not the kind of person to have a favourite text editor you're probably not the target audience of this post.
|
||
|
|
I talk mainly about software projects, since that's my bias/experience, though I think the principles are widely applicable.
|
||
|
|
You have been warned.
|
||
|
|
|
||
|
|
Having a number of side projects, I like to adhere to the principle of making it as easy as possible to start work.
|
||
|
|
Though often distract by shinier objects, I try to keep as many interesting projects ticking over at once.
|
||
|
|
Projects vary in scope, tooling and complexity and are driven mostly by fleeting bursts of inspiration.
|
||
|
|
|
||
|
|
This in mind, I find it's best to keep my project management as light and available as I can.
|
||
|
|
Though card-based kanban or scrum based tools like [Trello](https://trello.com/), [Jira](https://www.atlassian.com/software/jira) or the issue trackers integrated into [GitHub](https://github.com/features/issues) or [Gitlab](https://docs.gitlab.com/ee/user/project/issue_board.html) are great for team coordination, planning releases and responding to customer feedback, I find them a bit cumbersome for stream-of-consciousness making-for-fun.
|
||
|
|
|
||
|
|
For one, they all need an internet connection, and a full-fat web-browser to boot.
|
||
|
|
That's a lot of system load (read: a lot of battery use!) for what is really just glorified post-its.
|
||
|
|
Browsers also carry a distraction risk; I might start with good intentions but new tabs are just too easy to open.
|
||
|
|
They also need a login. I would hate to come back to a project years from now after combing through an old hard drive to find its tasks locked in an long-lost account.
|
||
|
|
|
||
|
|
Instead, I keep project notes in nested todo lists, or todo trees.
|
||
|
|
They look like this:
|
||
|
|
|
||
|
|
```
|
||
|
|
* [x] landing page
|
||
|
|
* [x] gallery
|
||
|
|
* [x] add pictures
|
||
|
|
* [x] apply styles
|
||
|
|
* [x] responsive design
|
||
|
|
* [x] about
|
||
|
|
* [-] blog
|
||
|
|
* [-] write some blog posts
|
||
|
|
* [x] git server
|
||
|
|
* [-] todo trees
|
||
|
|
* [x] self-referential humour
|
||
|
|
* [-] cogent argument
|
||
|
|
* [ ] referencing
|
||
|
|
* [ ] relativistic ray tracing
|
||
|
|
* [ ] generate html
|
||
|
|
```
|
||
|
|
|
||
|
|
I'd just like to take a few paragraphs to explain why I like this method of organisation.
|
||
|
|
|
||
|
|
## Flexible, accessible
|
||
|
|
|
||
|
|
Keeping it simple means it can be used in simple tools.
|
||
|
|
Simple tools have limitations, which often play to their advantage.
|
||
|
|
For example, using a monospaced font I may be restricted to only a hundred or so columns per line, which will of course restrict how long I can make an item and still have it be readable.
|
||
|
|
This isn't actually a limitation at all, but instead encourages me to write short items that are to the point.
|
||
|
|
If something is more complex, I can add sub-items.
|
||
|
|
The end result is that my items start to read almost example like the commit messages I'm about to make while implementing them.
|
||
|
|
|
||
|
|
## Learnable, memorable, imperishable
|
||
|
|
|
||
|
|
Just from looking at an example it's clear how it works.
|
||
|
|
There's basically one rule:
|
||
|
|
|
||
|
|
> Items with sub-items cannot be completed until all sub-items are completed.
|
||
|
|
|
||
|
|
I don't need to remember any features of any organisation tool.
|
||
|
|
I can create a list on anything with a text editor (it is a bit awkward on mobile, but so is kanban).
|
||
|
|
It will still be readable and make sense decades from now.
|
||
|
|
|
||
|
|
## Todo-aided design
|
||
|
|
|
||
|
|
Projects are often structured like trees.
|
||
|
|
In a physical sense (insofar as digital files are physical) filesystems impose a tree structure on collections of files, organising them into directories, and so software projects are virtually all trees of some kind.
|
||
|
|
In a (frustatingly) less tangible sense projects can be regarded as trees when describing their features, too; a website has a landing page, a navbar, a hero image, a footer...
|
||
|
|
|
||
|
|
As such, organising todos into a tree encourages design that meshes with a view of the finished thing.
|
||
|
|
When I find myself adding suspiciously similar-looking sub-items in different parts of the tree, I often find it's because I've made some design errors.
|
||
|
|
It's a good opportunity then to re-think my current design and re-organise the tree to fit.
|
||
|
|
Which brings me nicely onto...
|
||
|
|
|
||
|
|
## A living document
|
||
|
|
|
||
|
|
A frequent issue with any project documentation is that it goes stale.
|
||
|
|
This is rarely good, and can have a range of effects from being outright wrong to just making every search for truth into a miserable trudge through reams of information which just isn't relevant.
|
||
|
|
This is particularly an issue in wikis, as almost all the information is deliberately (though quite understandably) not visible at any one time, making it forgettable, forgotten, and ultimately opaque.
|
||
|
|
|
||
|
|
With just a todo tree however, the cost of re-organising is low.
|
||
|
|
Those comfortable with their [favourite text editor](https://ash-k.itch.io/textreme) will be comfortable moving lines around, indenting whole blocks, and adding or removing items in bulk.
|
||
|
|
|
||
|
|
I also feel no qualms about deleting things often. After a little while hacking a way at a project, todos quickly become outdated and unnecessary, as designs or intentions change.
|
||
|
|
That's fine and a natural part of project development, so it's healthy to cull them every once in a while.
|
||
|
|
Because they were so little effort to create, it's also not painful to let them go.
|
||
|
|
In a project with source control, deleted items can always be retrieved later if they are really missed.
|
||
|
|
|
||
|
|
These elements help to keep a project focused, though still leave room for the random meandering exploration that makes side projects so much fun in the first place.
|
||
|
|
|
||
|
|
## Built-in scope control
|
||
|
|
|
||
|
|
The most obvious limitation of todo trees is their linearly increasing complexity.
|
||
|
|
As a project grows, more features are added, which are broken down into more tasks, more indents, more sub-items until it becomes unmanageably large.
|
||
|
|
However, from another perspective, we see this isn't actually a limitation, but rather a feature unto itself - it keeps the project scope in check.
|
||
|
|
|
||
|
|
Scope creep is a universal problem, and though orgnaisation tools may promise the moon in helping its users overcome it, ultimately that is the responsibility of the craftsperson, not their tools.
|
||
|
|
By keeping project documentation and management light on the ground during prototyping, the most focus can be given to the creation, to validate the idea as quickly as possible before over-committing.
|
||
|
|
An upper limit to project management items discourages over-planning and encourages clearing completed items, which keep the project moving and not getting choice paralysed when picking up the next thing to do.
|
||
|
|
|
||
|
|
## Final remarks
|
||
|
|
|
||
|
|
I definitely didn't come up with this, but I also haven't seen it described as a project management strategy before either.
|
||
|
|
I got the idea from [GitHub-flavoured Markdown task list items](https://github.github.com/gfm/#task-list-items-extension-), but notably most renderers will only show three levels of indentation.
|
||
|
|
As such I like to just use monospaced text editors to look at and manage todo trees, whichever is the most available.
|