From af1abc0b051802e0a305d45a78541320d47b33a0 Mon Sep 17 00:00:00 2001 From: ktyl Date: Fri, 27 May 2022 01:11:18 +0100 Subject: [PATCH] remove unfinished --- blogs/unfinished/todo-lists.md | 103 --------------------------------- 1 file changed, 103 deletions(-) delete mode 100644 blogs/unfinished/todo-lists.md diff --git a/blogs/unfinished/todo-lists.md b/blogs/unfinished/todo-lists.md deleted file mode 100644 index e7f6e9f..0000000 --- a/blogs/unfinished/todo-lists.md +++ /dev/null @@ -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.