Slides from a talk I gave at Launch Academy in Vancouver, B. C. on 4 April 2013. The talk is an overview of CRA's SR&ED program and how to meet its requirements while maintaining an agile development methodology.

1. Canada’s SR&ED
Program

2. Part I: Basics

3. Key Points
refundable tax credit: partial reimbursement for
money spent on technology R&D
not a grant: if you meet the criteria, you get the
money
part of your corporate tax return
SO INCORPORATE ASAP (bconline.gov.bc.ca)
must file within 18 months of corporate year end
usually get paid 3 - 6 months after submission

4. Application
two parts to the application
- financial calculation of the tax credit
- report (proves eligibility)
supporting documentation (more about this later)

5. The Report
Always in 3 parts:
1.Technological Advance
• technology improvement
1.Technological Obstacles/Uncertainties
• proof that the work isn’t “routine”
1.Work Done (“War Story”)
• what you did to solve the problems
• doesn‘t have to be successful

6. Tech. Advances
• Performance improvements of any size
• Design and coding of a prototype
• Integration of software components
• Architectural improvements
• Framework extensions
• New or improved algorithms
• Any kind of reverse engineering
• Some types of factoring

7. Tech. Obstacles/Uncertainties
• Tech. Obstacles more important than Tech.
Advances (TO implies TA)
• Ensures that work isn’t “routine” (subjective and
personal)
• Hardest and most important part of the claim
• Developers forget problems
• Identify them at the beginning

8. Work Done
• Think high school science experiments
• More on this later

9. Part II: Not-So-Basics
• Writing reports
• Audits

10. Developer’s View
feature1 feature2 feature3
Product
Technology Stack

11. Developer’s View
where the important stuff happens
feature1 feature2 feature3
Product
Technology Stack

12. CRA’s View
feature1 feature2 feature3
Product
Tech. Obstacle1
Tech. Obstacle2
where the important stuff happens
Technology Stack

13. CRA’s View
feature1 feature2 feature3
Product
Better Technology Stack

14. Reality
Tech
tu re2
fea
Techn
. O bs
duct ology
Pro Stack
le1
tacle
feature1
s tac
ch . Ob
fea
Te
2
t
ure
3
Reality doesn’t matter: report must
conform to CRA’s expectations

15. Audit
a small percentage (10%?; 25%?) of claims
are audited
delays refund; usually reduces refund
common (?) for first year companies
added scrutiny of reports
scrutiny of documentation

16. Documentation
Not submitted with claim; back-up for audit
Examples (more is better)
- time records (weekly or monthly)
- test plans/experiments
- source code (complete version history)
Documentation is CRA’s sword and your
shield

17. More checked boxes lower chance of audit

18. Part III: What’s Changed

19. Software Startups Are Agile
• Less documentation
• Less time tracking
• More use of online tools (Jira, Pivotal, etc.)
• Daily “standups” replace more formal project
meetings

20. CRA Is More Demanding
• Fixation on “cheaters”
• Extra money for more audits
• More aggressive cost-recovery
• Probably trying to eliminate small claims
• Actively working to deny/reduce claims –
usually citing “lack of documentation”
• Explicitly rejects agile methodologies

21. Part IV: Fight the Power

22. What to Focus on
• Time tracking against Tech. Obstacles
• Experiments
• Other stuff

23. Tech. Obstacles/Uncertainties
• Components A & B were not designed to work
together.
• Will Component X perform adequately?
• There is insufficient technical documentation to
determine if Component X is a good choice.
• Can I successfully integrate Component X into my
existing framework?
• How will the system scale under load?
• No algorithm/tech exists that does what I need.

24. How to Find Tech. Obstacles
1. Ask about tech problems at standups
2. Things that take a long time
3. Map features to tech. obstacles
- common, but risky in audit
• Identify at project start
• OK to change/add tech. obstacles
• Document them somewhere

25. Time Tracking
• Need to assign developer time to each Tech.
Obstacle
• Also have to record non-SR&ED time
• Use a spreadsheet or a tracking tool
• CRA can’t assess accuracy

26. Basic Time Sheet
week beginning SR&ED non-SR&ED Notes
Tech Obstacle 2
Tech Obstacle 1
1
10-Aug-09
2
17-Aug-09
2
24-Aug-09
3
4 31-Aug-09
5 7-Sep-09
6 14-Sep-09
One sheet per developer
Requires 2 minutes/week

27. Tracking Tool
Pick List Hours
Tech. Obstacle 1
Tech. Obstacle 2
....
Non – SR&ED
• Require this for check-in

28. Experiments
CRA view: experiments are how TOs get resolved
•Developers don’t think this way, but often do
- explore alternatives
- decide what’s best based on testing
•What matters are the experiments
•Coding is “support work”
•Support work counts

29. How to Do Experiments
Just like high school:
•Hypothesis (1 sentence)
•Description of experiment (1 sentence)
save •Input data
everything!
•Test bed (code, framework, db, etc.)
•Results (Measure Something!)
•Analysis & Conclusions (1 sentence)
The sentences are optional

30. Experimental Questions
Developers routinely ask questions that lead to CRA-
type experiments:
•What’s the best way to implement this feature?
•What are the resource requirements for this feature?
•How will this feature impact performance?

31. Turning the Tables

32. Other Stuff
• quick and dirty is best
• the digital shoe box
• Tag emails or cc to SR&ED@yourcompany.com
• record standups
• photograph whiteboards
• Etc.

33. Thanks!
Questions?
ed.levinson@analusis.ca

34. Ineligible Work
• Developing/implementing a business process, work
flow, game rules
• Simple UI changes
• Straightforward implementation of a known
algorithm
• Some kinds of factoring
• Bug fixes on production code
• “reinventing the wheel”