No, the primary outcome will be the proper bifurcation of software programming between programming (currently expensed) and engineering (capitalized). For exam

No, the primary outcome will be the proper bifurcation of software programming between programming (currently expensed) and engineering (capitalized). For example, identifying what to do (program features) and how to do them (program structure) is R&D work. Test development is also R&D work (since the development of QA processes is considered R&D, even though the QA activity itself usually is not). Coding software to spec based on known outcomes, structures and/or tests is not R&D. It's just coding. It should never have been treated as R&D, and doing so was always an aggressive tax position to take; while common in SV and Fortune 500 companies, on the whole it is actually uncommon for most companies to treat software programming as R&D. And it's not even all that devastating for SV as an industry, since you have to have profits for this tax change to matter, and profits aren't something that SV companies are known for. Meanwhile, since most companies never treated in-house software programming as R&D, they're unaffected by this change, and this is demonstrated by the tax industry's lackadaisical response to this change since most of their clients aren't impacted.