Speaking from a background of algorithm research:
- Keep a long backlog of ideas
- Re-prioritize aggressively and frequently (e.g. every day)
- Mark down backlog items that are no longer viable
- Maintain an up-to-date picture of inter-dependencies between backlog items
- Unlike regular software development, there is a lot more dependencies in research work.
- Always measure, visualize and track algorithm performance (accuracy, etc)
- Don't work alone.
- Discuss, collaborate and share frequently.
- Keep a wiki, and spend lots of effort to extract "wisdom" from your work.
- Use version control. However, keep good algorithm candidates in the current system, even if they are not actively used.
- It allows you to tinker with an older algorithm at the spur of the moment.
- Stale performance data could be error-prone.
- For example, the old data may be based on a less accurate metric
- To get fresh performance data, re-run the algorithm(s).
- Prefer dynamic typing and flexibility.
- Use the right language.
- If almost all successful researchers in the field use one particular language, then use it. Don't fight the wisdom of the crowd.
- Instead, find ways to integrate smaller components into that language, if the smaller components can be developed in a language suitable for computation such as C/C++, or if existing open source code is available.
- Ask fellow researchers for their source code.
- Many researcher are actually quite friendly to such requests with proper credits and data sharing.
- This will save a lot of trouble because their published papers will only cover the high level picture, yet the devil is in the details.
- Always push yourself, but don't timebox.
- Timebox don't work because of unpredictability in research work.
An example of how to use backlog in research: Suppose in the beginning there are items A, B, C, ..., X, Y, Z.
Over time, you worked on a number of items, and you have a sense of how promising each item is, not just the items you have worked but also those you don't. The updated backlog becomes:
- A (promising: 90, progress: 70% done)
- B (promising: 70, progress: 60% done)
- Z (promising: 65, not started)
- C (seems it won't work, don't bother)
Notice how item C sinked to the bottom because of research insights gained from working on A and B. Also notice how Z floats to the top. Learning about what other researchers are doing will also help floating items to the top.
At the end of one semester, do a backlog cleanup.
- A (done, working)
- B (done, working)
- Z (done, some bugs)
- Y (50% coded, kept in the system, not actively used)
- X (10% coded, removed from the system in revision 123)
- C (dropped)
The ones that are working will be the result you publish.