John Walker on May 17, 2007 00:34 sez:
I'm all for the KISS principle. Text files are awesome things if used correctly. I remember reading something regarding MS Live Spaces where some of their data was being stored statically in text files...and that it was done specifically for scaling reasons. If I find the reference I'll post it - may have been Dare Obasanjo from MS.
I agree...you can cross that bridge when it comes to it.
Suraj Barkale on May 17, 2007 02:20 sez:
As long as you can parse the data when you need it (and I am not talking about *outsourcing* the parsing :)
Rik Hemsley on May 17, 2007 02:48 sez:
I always used to use a text file for my TODO stuff - but then I started using OneNote, because it lets me organise stuff slightly better without getting in my way.
I would be absolutely happy to use a text file for a shared TODO list, though - as long as the other people working on it were as fastidious as me.
James Gregory on May 17, 2007 03:12 sez:
I'm a big fan of text files, and as John said, KISS. I use them for simple application configs as well, saves on the XML parsing.
Text files for TODOs is a very good idea. Bits of paper get lost, websites are a distraction and software requires interaction on your part.
Peter on May 17, 2007 05:12 sez:
You're trading off the burden on the writer against the burden on the reader. When there are just two guys reading the file, POT makes sense.
Having said that, using a wiki format might have some benefits. It's hardly any extra effort, and the wiki-viewer lets you see images and browse links more easily ... but maybe that adds other complications.
moops on May 17, 2007 06:21 sez:
text files? real developers dont need an IDE like notepad.exe to get things organised. My team and I just scratch todo items onto the side of the cave wall with a bit of burnt stick
David Mohundro on May 17, 2007 06:25 sez:
I like it. I mean, what do you need to set it up?
Hmmm... notepad - check. That was easy!
We actually have been using a shared OneNote notebook on our team and it has worked out well. I don't know how well it would work if the team isn't all on the same LAN, though.
dave solomon on May 17, 2007 07:18 sez:
Why not split the difference and dump your stuff into TiddlyWiki? It's a standalone HTML file that, through EVIL MAGIC, presents itself as a Wiki. I used to use a POT file for my ToDo list, but having dates and times and tags is easier.
TiddlyWiki double-rules because you don't need to futz with a server install and the database config and yadda yadda; all you need is an interweb browser (and not even a connection to The Internets because it's a local HTML file).
Jason Moore on May 17, 2007 08:25 sez:
Unless you make some specific tool for managing your text file, then you lack the ability to do reports and it can be difficult to come up with an easy to follow schedule. Like you said, you only have two people and that may not be a big deal.
I definitely can understand not wanting to waste time setting up a tool and learning how to use it. I'm part of a small team of developers (3) and we tried using bugzilla for a while, but it ended up being a pain in the arse and nobody used it. Since then we switched to a program called Gemini (http://www.countersoft.com/) and tracking todo items has been a breeze. It's all web-based so you don't need anything except a browser to deal with it.
Haacked on May 17, 2007 10:31 sez:
I like the wiki approach myself. Presenting images is important for discussions. That whole 1000 words things.
John Radke on May 17, 2007 12:34 sez:
I thought you were ca-razy until I read that there's only two developers. Then it's much less crazy. Worrying that it's not gonna scale is just premature optimization.
But I would still go with a wiki because it'd be simpler. Currently you have to make your change & commit it, then later when you look at it you have to make sure to get the latest version from source. Or you have to do that lame checkin/checkout procedure. Either way, it's less work to use a wiki, with all of the benefits.
Matthew Martin on May 17, 2007 17:25 sez:
I think the key here is that you are using source controled todo lists, which through diff reports creates some important feedback on each check in--what has been finish and what new needs to be done. This is an entirely different work flow than exchanging a todo list by email or keeping it on a shared drive. That said, the cost of starting to use a real bug tracker, like flyspray keeps falling.
Paul Kohler on May 17, 2007 21:09 sez:
I am a huge fan of the simplicity of text files. Why complicate things with XML (which is still a text file whose 'format' can be broken.)
There are enough other things in the coding world that make life difficult - stick with text!
Harold on May 17, 2007 23:08 sez:
Right on brother. I've been using a text file as my personal wiki for many years. It's the first thing I open in the morning, write a mini to-do list for the day, then keep notes, urls, whatever all day long.
Charley Farley on May 18, 2007 09:37 sez:
Can anyone who uses a text file for their "personal wiki" or "todo" list post an example if they have any tips to share on making the most of a plain-text format?
The main post states "It's a semi-structured text file, in the sense that we have conventions we use for keeping it tidy." What form do these "conventions" take?
I'm just trying to rekindle the flame to start using a text file again for this. I've done it before but always end up giving up because, once it gets busy, it ends up being quite difficult to scan through to see "what's next."
Thanks.
Ben on May 18, 2007 10:45 sez:
Text files are exactly what I use at home on my personal projects.
At work, we used to use Word documents when it was just me coding, and my manager managing. It turned out, that it didn't scale at all, once we added one more developer, and a few other people got involved and needed to be kept in the loop. A bug tracking system was setup, and it's worked wonders.
At home, with just me, that would be way too much overhead. txt works great.
Harold on May 18, 2007 18:20 sez:
Charley,
My format is records with %% separators and a simple date at the top. I use keywords like TODO, HOWTO, or INFO. Every morning I start a new entry and write a quick TODO list for the day (typically copying up stuff I didn't do yesterday!).
Fri May 18 2007
TODO:
- make a million $
- quit job
%%
Charley Farley on May 19, 2007 03:44 sez:
Harold,
Thank you so much, this is just the sort of level of detail I was hoping for.
Do you leave all the previous days' entries in the file? Do you delete todo lines you've completed or simply change the - to a +?
Your approach seems to be a mix of a "todo" and a "done" list?
I keep a Word document at work, a simple macro inserts today's date and I keep a bulleted list of things I've done (so I can recall them to the boss when he asks what I've been up to!) It also doubles as a cut/paste notepad for snippets of code. Each year I rename Diary.doc to Diary_yyyy.doc - I have them going back to 2004. They are indexed by Google Desktop so old entries are easy to find.
However, for portability and lightweightedness(!), I'm looking to a plain text file for my todo list (not my done list).
At one point, following GTD I had a nextactions.txt, projects.txt and somedaymaybe.txt but I found it impractical jumping between them. However, whilst I agree that "next actions," tangible items you can actually do (purchase 5L of white emulsion from DIY store) work MUCH better than fuzzy todos (decorate house) keeping future next actions for the same project is important so you don't forget (e.g. put dustsheet over computer) and if they all go in the same file, I find it difficult to see the wood for the trees?
Does anyone have a good solution that works for them?
Charley
lb on May 19, 2007 03:54 sez:
for my personal list of todo items -- here's the basic plan.
Each day when i start:
i write today's date at the top of the file.
Then i copy the list from yesterday, and paste it in under today's date.
Any tasks that were done I remove from this copy. I then add new tasks, and delete any tasks that i've decided aren't really needed.
Each task has a '[_]' at the start of it (a poor man's check box) -- and if the task is 'done' then i change it to '[x]' -- and it will be deleted the following day.
i use indenting to indicate a hierarchy of tasks.
Throughout the day, new tasks are added, and other tasks are completed.
i keep a close eye out for tasks that are 'undoable' -- and try to break them into smaller tasks or work out what questions need to be asked (of whom) in order to make them into real tasks.
For timesnapper we have a different technique -- as it is not a 'day to day' list -- but an ongoing list.
We archive completed tasks, after each release, to the bottom of the file, with the release that they were included in.
We list current tasks under the form/class they belong to.
We list the email address of who requested a task -- so we can tell them when it's done.
Before the '[_]' (poor mans checkbox) for a task, we prefix a note like '??' meaning -- needs clarification, or 'do' meaning -- urgent, or 'lb' meaning lb will do it, or 'no' meaning, 'not to be done' etc.
At the top of the file is the upcoming version and all the features/bugs to be fixed in it. Then there's the version after that and what we project for it, and so on for several versions. Tasks get clearer when they're nearer to the top.
There's also headings for Marketing, Other Products, Website Ideas, and many more things.
Many angles to work on... and so little time.
lb
Richard on May 19, 2007 09:42 sez:
I'm using BaseCamp with a client, and it rocks:
http://www.basecamphq.com/
Free for one project, and pricing is reasonable after that.
Harold on May 19, 2007 16:15 sez:
Charley,
That's exactly what I do (like lb) - I mark done items with a + and the next day only copy up the "not done" items. Sometimes I leave a complete copy of the list behind, or sometimes I'll abandon an old list if it turns out I'm really not going to do it after all.
I used to keep this kind of "work log" in real notebooks, but these days I'd be crazy to write down a url.
The "work log" technique is
Scott on May 22, 2007 10:56 sez:
For a team with your size and discipline, a text file is fine. Keeping it in version control is very smart. I work in an organization that uses Excel files for bug tracking (and doesn't version control them). Frustrating doesn't even begin to describe the situation.
Brian Dewey's TODO Tracking Powershell scripts on July 29, 2007 19:58 sez:
(putting a link here to brian's scripts so i can find them again)
Micah on January 04, 2015 07:12 sez:
Hey! This is kind of off topic but I need some advice from an established blog. Is it very difficult to set up your own blog? I'm not very techincal but I can figure things out pretty fast. I'm thinking about making my own but I'm not sure where to begin. Do you have any tips or suggestions? Appreciate it