Re: Outlining a project.

A very good book pack on this topic is ISBN 0735605971, especially Software Project Survival Guide by Steve McConnell (again). The latter one has a lot of templates and checklists, suitable mostly for larger projects.

A nice, if somewhat pedantic book on planning your personal work is Introduction to the Personal Software Process (ISBN 0201548097). It contains a lot of advice of how to monitor your own work process, including a lot of forms to record more or less relevant information. While the whole pack might be more of use to really bureaucratic types, the part on time recording and the part on recording defects in your programs are definitively worth reading.

Third, I want to follow up the recommendation by lachoy on the Pragmatic Programmer book. If you want to enjoy the wisdom of this book on your command line (similar to the Unix fortune command), try this script.

And, last but not least, never forget that planning has something to do with thinking. Planning is not following plans blindly. Always ask: What do you really want to achieve? Everything else follows from that. Some tools for thinking (funny, eh) are taught in the aptly-titled The Thinkers Toolkit (ISBN 0812928083), which is really a cool little booklet with a good value for its price.

In fact, planning is like programming at a higher level - but with a new, ever changing runtime environment each time, and without debugger.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Edit: chipmunk 2001-03-20

Comment on Re: Outlining a project.

Replies are listed 'Best First'.
Re: Re: Outlining a project. by providencia (Pilgrim) on Mar 22, 2001 at 01:01 UTC
Thanks a lot for the tip script. I will definitely be checking out Pragmatic Programmer book (despite the fact that the author collaborated on Programming Ruby: The Pragmatic Programmer's Guide)	[reply]
Re (tilly) 3: Outlining a project. by tilly (Archbishop) on Mar 22, 2001 at 09:51 UTC
Actually both books have the same two authors. But why would their having collaborated on a Ruby book make you turn your nose up at a general programming book? This sounds more like bigotry to me than anything else. The best programmers in any language tend to know several - and like multiple ones. It is much easier to notice that a language over there has a nice feature that works well and borrow it than it is to come up with original ideas. Larry Wall knows this well, which is why Perl derives from so many sources. I hope he continues to do so. Also see Why I Hate Advocacy by Dominus. And think carefully about what he has to say. Don't knock a new tool until you have tried it. And just because someone likes one tool that you don't is no reason to never deal with them again.	[reply]
Re: Re (tilly) 3: Outlining a project. by providencia (Pilgrim) on Mar 26, 2001 at 23:49 UTC
You make an excellent point. I want to thank you for the link to the article as well. I'm in the proccess of reading it right now and wanted to let you know that I am finding it enlightening. I think I am misplacing my appreciation for Perl with advocacy. This is the first time I can recall that I've ever "advocated" Perl with or without bias. I feel very fortunate to have gotten your reply. Many Thanks	[reply]