I've been reading Dreaming in Code by Scott Rosenberg. This book is supposedly the new must read for software programmers. I am half way through it, but can't say I particularly like the book much so far. It's about the Chandler project, which aimed to replace Outlook in the desktop world, and ended up being an utter failure. To my surprise, Andy Hertzfield was in that project. Basically, Kapor(the founder and funder of the project) was way to ambitious and therefore created a situation where deciding on the spec was near impossible and therefore actually coding happened extremely slowly. I think that this is something that the agile people have learned to avoid though, so I don't really feel that I have learned anything new. Basically it feels like that I have already learned the lesson of this book. But you never know, I'll finish the book first.
I do have some thought about what to do and what to avoid when you tackle a programming project, so let me share them here:
- Eat your own dog food - I think this is probably the most important rule of all. But it is especially when you first consider persuing a project. Is this something that you will use and will enjoy using? Don't work on a project the product of which you will not use, because 1) you will not enjoy working on it and 2)it will not be good(because of the first reason and the fact that you will not have a fast feedback loop to make sure it's high quality).
- Be agile - being agile is important because 1) you want to get things going quickly so that you can "Eat your own dog food" asap 2) you want a very quick feed back loop from the user (you) back to the programmer(you again). What this means is that you don't want to design everything up front before you start coding. You want to code just enough so you can start using it, then come up with a list of things that are wrong with it, prioritize the list, and then go redesign/fix them, because a lot of ideas don't come up until you have had the experience of using something, and it should feed directly back into the design.
- Don't aim too high - this is related to being agile also, but basically, start small, and don't try to solve too many problems at once, because it won't work and you will get bogged down on failing to put the big picture together and get depressed and lose interest for the project.