This week, I’m joining a group of representatives from the Irish games industry in a meeting with government policy advisors, to help establish whether or not games development should qualify for the R&D tax credit. There are many aspects to game development, and everyone has their own perspective, but I thought I’d try to clarify my own thoughts here.

Current Situation

A significant tax credit is available in Ireland for research and development work done in companies. R&D is performed by high value workers, and leads to the generation not only of intellectual property, but of intellectual capital. This helps address the issue of footloose multinationals, and also helps build up the country’s high-tech workforce, making Ireland yet more attractive to new foreign companies, as well as fostering the creation of new indigenous high-tech companies.

Strangely, although software development is considered generally eligible for this tax credit, there’s some confusion whether the same is true for games development. I have no idea where this originated from. Perhaps the fact that video games are generally bought on DVDs and experienced on the TV resulted in someone lumping them into a bracket with film production. Of course, this is wrong. Perhaps more than any other field of software development, games development pushes the cutting edge of technology.

It is intrinsically R&D

Games development is a kind of software development, and all software development is a process of continuous invention, experimentation and learning. Nowhere in software development is this more true than in games, where technological possibilities are constantly pushed to the limit.

I have experience with university research. I was education officer in Trinity College, and was a member of the college board, the university council and pretty much every other academic committee going. I was a graduate student in the computer science department, and was the graduate student representative for the school of computer science. Since that time I have been involved with diverse software companies, and I can categorically say that what goes on in them is basically the same as in university, only ten times faster and with commercial success (not one’s publication record) as the goal.

I often find myself struggling to communicate aspects of software development to people. It is a highly abstract and revolutionary field, and it’s no wonder that non-developers have difficulty understanding what we’re doing. Some people clearly think that software development is about typing things very quickly into computers. Luckily, most people understand that it’s a difficult field, but neither expect nor want to know any more about it than that. It could be because of this that games development has been lumped into the same category as film development and denied its tax credit.

So I want to try a rather simplified analogy to clear this up. Say a helicopter is being designed by some boffins, whose work culminates in a detailed set of blueprints for its construction. Production then commences, with actual helicopters being constructed based on the blueprints. Here we think of the work of the boffins with their blueprints as the R&D bit. The actual production wouldn’t qualify. In software development all we do is invent these blueprints. The blueprints are equivalent to the computer code. No two blueprints are alike, none of them works the first time, every one of them takes inspiration and extreme mental effort to create. Now, the field of software has the special property that actually creating a product from the blueprint can be done at zero cost and zero effort. All you need to do is run the program.

Basically, all software development should be considered R&D. If there’s a software developer developing software, then (s)he’s doing R&D.

A multidisciplinary holistic enterprise

It is possible that it is not the programming end of game development, but its accompanying disciplines that have cast doubt over its eligibility for R&D. Game development involves a mix of hardcore software development, games design, 2D and 3D art, scriptwriting, play testing and adaptation work to different hardware platforms and locales. Standing alone, some of these elements would be categorised in the humanities, not the sciences. However, game development is a holistic enterprise, in which all of these elements are tightly woven and inseparable. The process is iterative, and involves people of all disciplines rapidly responding to the work of everyone else. The game programmers strive to do justice to the 3D artwork, while the artists innovate in response to new abilities of the game programming. No single element can be extracted from the rest and make sense as a standalone activity. The goal is to create a game that harmoniously combines technology and design to produce an experience superior to what came before.

This is not unique to game development. Consider Apple’s achievements with the iPhone. The iPhone represents a pinnacle of technology combined with excellent industrial design and user interface design, honed through testing. It’s absurd to think that Ireland would refuse the iPhone team R&D status because they had so many designers and testers on staff. Without its design and testing, the iPhone would have been a poor competitor to the N95, and Nokia would still be a company you would invest in.

To a game studio, every game is the next iPhone. They are on the cutting edge, marrying design and new technology together in new ways, aiming to create a revolutionary experience.

No detailed records

One requirement of receiving the R&D tax credit is that the company be able to furnish up on request detailed records of the research being performed. Although the intention is that these records should align closely with what is already being kept, this is far from the truth (at least for software development).

There are detailed requirements that records be kept describing each hypothesis advanced, each experiment performed to advance the hypothesis, various dated documentary evidence of each piece of work, what it was for, how it was carried out, how conclusions were drawn, what conclusions were drawn… and lots more.

Perhaps these kinds of records are routinely kept in the pharmaceutical research companies. I can say for sure that they are not kept in software companies. Over the last 10 years, commercial software development has embraced Agile methodologies. A result of this is that the focus is now on rapid development iterations and customer feedback, a move away from large amounts of preliminary and ongoing documentation. In general, software companies will keep as little documentation as possible. Perhaps they can get away with it because the software code and its various user interfaces are an effective substitute. Whatever it is, the documentation requirements for the R&D credit cannot be met by a modern software development company.

Summary

Although I feel that every software company I have encountered logically qualifies as R&D, as games companies they may not officially qualify. If they did qualify, the record keeping requirements would be impractical for them to comply with.

As someone who just wants to get on with company building, I need it to be simple. I’d like to get the tax credit on the basis that we do software development, and software development is intrinsically R&D. With that resolved, I don’t see why I should need to provide any records other than to show how much was spent on software developers developing software in my company.

Archived Comments

June 22, 2011 at 11:39 pm, Naoise Gaffney says: Very interesting post, Sean. You appear to put forward two points here:

1) That the development of all software should be eligible for the R&D tax credit 2) That games, as a form of software should also therefore be eligible

As I understand it, R&D tax credits are not currently available for all software (just as the tax credits are not available across the board in other industries). Presumably this is because otherwise, the simplest novelty smartphone app, as “software” would qualify as tax-deductible R&D. To use your analogy, I believe the reasoning is that tax credits should only be available to folks who produce blueprints for helicopters, and not to folks who produce blueprints for two-piece jigsaw puzzles. Otherwise a scenario would develop where the R&D tax credit scheme was being abused. Such ‘abuse’ of the related patent royalty tax break was the main reason why this tax break was canned last November (setting aside whether one believes such a tax break was a good idea in the first place).

By drawing a line in the sand, I believe the State has tried to ensure that only innovative, ‘meaty’ programming projects are rewarded with the tax credits, and that relatively straightforward implementations and automations are not. The problem is that this line they have drawn is not the clearest.

However, having said all this, there is no reason why some gaming products should not be eligible for the tax credits. You make a pretty good point that with respect to the games industry. For software companies trying to avail of these tax credits (and agile programmers in particular), the documentation requirement is likely a greater burden than in other industries. In addition to this, the games industry suffers from an additional perception problem whereby it is labelled “arts” or “entertainment” rather than “technology”, with tax credits refused on that basis. This is obviously a very facile – and borderline ignorant – way of looking at the industry for the reasons you suggest. I would be curious to know whether the taxmen put producers of gaming middleware into this same bracket. An even easier case could be made that such companies engage in qualifying R&D, as there is no directly derivable “entertainment” end product with which to muddy the waters.

Best of luck setting the record straight with the policymen.

June 23, 2011 at 11:10 am, Sean Blanchfield says: Thanks for the interesting points, Naoise. However, I don’t see a qualitative difference between the “helicopter” and the “two piece puzzle”. The difference is only a quantitative one. It might take €5m to make the former, and €5k to make the latter, but since the R&D credit is only on the “incremental cost of in-house, qualifying R&D“, there is no need for a policy distinction between them. A developer making a two-piece puzzle game for iPhone will still have hurdles to overcome, just fewer of them.

June 24, 2011 at 10:56 am, Naoise Gaffney says:

Like it or not, Sean, I believe that trying to make a qualitative distinction is exactly what the government is trying to do. Doubtless, developers will always have hurdles to overcome, regardless of the size of the project, but it may be a bit of a generalization to imply that all hurdles are the same size and shape and that there’s just more of them in a larger project. Let’s for a minute apply the argument you put forward to another industry – take pharma as an example. I suspect that when a generics manufacturer tools up to start cranking out pills once a drug comes off patent, they may not be entitled to a tax credit for this. If the generics company already knows how to manufacture the pills, there is no real technical difficulty in producing them. Contrast this with the patent owner that initially discovered the drug and the amount of additional time and effort that went into the pioneeing work that resulted in the first use of this drug as a pill. I don’t think you can rightly say that the two organizations have both overcome hurdles of the same nature, but that the patent owner merely overcame more of them.

Without expressly saying so, I think the goverment’s goal here is to encourage “innovation” (yes – that much overused term). They appear to think that “innovation” is what stems from “Research & Development”, and have thus seen fit to make the policy distinction to which you refer. The Revenue stipulates that in addition to the notekeeping requirements you mention, it is necessary to identify “the scientific or technological advancement that is the goal of the research and development activities”, and “the scientific and technological uncertainty the company is seeking to resolve by those activities”: (www.revenue.ie/en/tax/ct/leaflets/research-dev.pdf). No doubt you are familiar with these requirements already. If -as it seems – the government wishes to reward only “innovative” work, regardless of the industry, I don’t think it would be possbile to convince them to extend a blanket eligibility to all programming activities. If this were done, the eligibility would then have to be extended to all currently ineligible activities in other industries as well.

Having said this, there is quite a strong argument to be made that the existing guidelines for applying the R&D tax credit were not drafted with programming in mind, and that as a result, the bar is set too high for the software industry. It is likely that some programming activites normally be considered “innovative” currently do not qualify as such using the Revenue’s existing criterion. Lowering this bar for the software industry by either modifying the existing guidelines, or developing a second set of guidelines for software may be the way forward…

June 25, 2011 at 10:44 am, Sean Blanchfield says:

I agree with most of what you say Naoise, but I think on the pharma analogy you’re missing one of the core assertions of my post.

I am asserting that software development is special because the act of developing the product is virtually all there is to the industry. The actual production of software (in comparison to the generic manufacturer tooling up) is completely trivial – it’s copying bytes onto discs, or transferring a file onto a website.

So, there the pharma analogy fails (along with the helicopter manufacturer in my example). Anyone creating a software product is faced with R&D challenges. There’s no equivalent to just taking a design and only having manufacturing/production challenges to deal with.

I would go even farther (not to intentionally bait you :-)), and suggest that even if someone is knocking off someone else’s original software concept (like a generic drug manufacturer), they will still have to re-solve nearly all the R&D challenges themselves (unlike the generic drug company).

June 28, 2011 at 11:01 am, Naoise Gaffney says:

Hm – I see the pharma analogy does not stand up if you are to consider the nature of the work involved at various points of the process. I hadn’t really intended comparisons to be drawn as to the nature of the work, merely that the magnitude of the hurdles be considered. To dispense with analogies completely, this boils down to a question of whether or not writing a “hello world” script in a known language for a known platform constitutes R&D. If a trivial task such as this is something everyone in the industry already knows how to do, the case for it qualifying as R&D is pretty weak.

Ulitimately though, it depends on your definition of R&D. Part of the problem here is that I think the State is making use of the term “Research and Development” as having scientific connotations – as I have previously said, I think they are using it interchangeably with “Innovation”. In this context, the meaning of “development” is not universally synonymous with the meaning of the term “development” as used by the software industry. Certainly, writing a “hello world” script is “development” by programmer standards, but it remains to be seen whether it constitutes “innovation”.