ktyl
/
blog
1
1
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

remove unfinished

This commit is contained in:
ktyl 2022-05-27 01:11:18 +01:00
parent e537233c5f
commit af1abc0b05
1 changed files with 0 additions and 103 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
blogs/unfinished/todo-lists.md
View File

@ -1,103 +0,0 @@
# 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.