Embed Size (px)
Citation preview
Canada’s SR&ED Program
Part I: Basics
Key Pointsrefundable 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
Application
two parts to the application
- financial calculation of the tax credit
- report (proves eligibility)
supporting documentation (more about this later)
The ReportAlways 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
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
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
Work Done
• Think high school science experiments
Part II: Not-So-Basics• Writing reports• Audits
Developer’s View
Product
feature1 feature2 feature3
Technology Stack
Developer’s View
Product
feature1 feature2 feature3
Technology Stack
where the important stuff happens
CRA’s View
Productfeature1 feature2 feature3
Technology Stack
where the important stuff happens
Tech. Obstacle1Tech. Obstacle2
CRA’s View
Productfeature1 feature2 feature3
Better Technology Stack
Reality
Productfeature1
feature2
feature3
Technology Stack
Tech. Obstacle2
Tech. Obstacle1
Reality doesn’t matter: report must conform to CRA’s expectations
Audita 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
DocumentationNot 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
More checked boxes lower chance of audit
Part III: What’s Changed
Software Startups Are Agile
• Less documentation
• Less time tracking
• More use of online tools (Jira, Pivotal, etc.)
• Daily “standups” replace more formal project meetings
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
Part IV: Fight the Power
What to Focus on
• Time tracking against Tech. Obstacles
• Experiments
• Other stuff
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.
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
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
Basic Time Sheetweekweek beginningbeginning SR&EDSR&ED non-SR&EDnon-SR&ED NotesNotes
Tech Obstacle 1Tech Obstacle 1 Tech Obstacle 2Tech Obstacle 2
12
10-Aug-09
2 17-Aug-09
324-Aug-09
4 31-Aug-09
5 7-Sep-09
6 14-Sep-09
One sheet per developerRequires 2 minutes/week
Tracking Tool
Tech. Obstacle 1
Tech. Obstacle 2
....
Non – SR&ED
Pick List Hours
• Require this for check-in
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
How to Do ExperimentsJust like high school:
•Hypothesis (1 sentence)
•Description of experiment (1 sentence)
•Input data
•Test bed (code, framework, db, etc.)
•Results (Measure Something!)
•Analysis & Conclusions (1 sentence)
save everything!
The sentences are optional
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?
Turning the Tables
Other Stuff
• quick and dirty is best
• the digital shoe box
• Tag emails or cc to SR&[email protected]
• record standups
• photograph whiteboards
• Etc.
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”
