When a visit comes from an R&D auditor, they will want to check on what work you have ‘experimented’ with.
An experiment, in R&D terms, translates to an iterative series of changes over the same piece of code. That means you will need to be able to show code you wrote that didn’t work. If you didn’t check that in at some stage, you are in trouble.
Forgetting to record failed experiments
Unfortunately for R&D, when a software developer is making changes to a system they do one of two things. Either it is correct and the work is committed then checked in. Or, it doesn't meet the spec and they revert the changes and try again.
This means you need to make drastic changes to your internal processes, recording a bunch more information in order to satisfy the R&D criteria.
Forgetting to record evidence of what was available at the time
Additionally, R&D requires you show the work you create is generating new knowledge for the industry as a whole. This means, you need to show that the code you’ve written, wasn’t already written by somebody else.
While developers communicate, there can be a lot of internal discussion and small decisions made. These discussions can be either in person, email or IM and all of these discussions could be required to prove your claim.
The last thing you want to do is read through old employee inboxes and conversations.
Follow the below rules and you will be solving these issues, ensuring you're in accordance with the Australian R&D regulations.
