Recently I have been learning about actigraphy as you will know if you read my last posting on my browser history. As I said in that article, I was working up to writing a new app for my Pebble Smartwatch to replace my Jawbone Up. It struck me as I wrote that article that I was doing something which seems more than a little unusual in the Open Source and Free Software community. Namely writing software for something I knew little to nothing about -- but taking the time to learn about it before putting hand to keyboard to get coding.
When we start projects, we naturally tend to select a name for it (after all, how can one create the git repositories, register domains, create a dev mailing list etc without a name?), and we decide on other important stuff like what licence to put it under. We write the README, perhaps a basic NEWS file and then comes time to start to write the design documents (or at least notes).
But, how many of us actually sit down and think "Perhaps I should gather up resources on the topic before I write my design?" Sometimes we're doing a project which is the research into the topic -- under that circumstance you might be forgiven skipping the pre-research step. Most of us, however, are writing code for already understood problems, even if we're going to be taking novel approaches to it.
I often find myself wanting to write a program just to learn about something. How many people do you know who have written regex execution engines "for fun"? But I always try and do a lot of research up-front so that I don't go into projects blind. Oftentimes that, when written up, takes does the form of a trivial README with an explanation of what the program will do, or perhaps a set of design notes (not end-user documentation, but simply notes for myself) which distill what I have learned into my design, but the research work really is behind the scenes.
For those of you who have followed the truisms series, and delighted in the homeworks set at the end of each article, I offer this: For whatever you're currently working on, take a step back and think if you really understand the problem domain you're working in. If you can't answer with an emphatic yes, and you're not doing a pure research project, then stop and take some time (perhaps only half an hour) to search around on the web and read a few papers (if any exist) to help you along.
Why not comment on this posting with how you get on?