The time bomb in the tax code that's fueling mass tech layoffs

Original Article ↗ Hacker News Discussion ↗

A little-known change to U.S. tax code Section 174 is forcing companies to amortize research and development costs—now explicitly including most software development—over five or fifteen years instead of expensing them immediately. Commenters argue this has sharply increased near‑term tax bills, squeezed cash flow, and hit startups and small software firms especially hard, while benefiting large, established players that can ride out the transition. Others contend that higher interest rates and post‑pandemic over‑hiring are bigger drivers of tech layoffs, and debate whether the old rules were an unjustified subsidy for R&D or a necessary policy to support innovation.

Scope of the problem: does Section 174 “explain” mass layoffs?

  • Many argue Section 174 cannot fully explain mass tech layoffs:
    • Most laid‑off staff weren’t doing what people normally call “R&D” (e.g. games, line‑of‑business apps, ops).
    • Other major drivers cited: end of zero‑interest‑rate era (ZIRP), pandemic over‑hiring, slower growth, Twitter’s high‑profile cuts, and classic wage‑suppression tactics.
  • Others counter that, for tax purposes, a huge share of tech headcount is classified as R&D, especially since the code now explicitly treats software development as R&D. So the rule change does affect a large fraction of engineers, PMs, data scientists, etc.

What actually changed in Section 174?

  • Pre‑2022: qualified R&D (including software dev if elected) could be 100% expensed in the year incurred.
  • Post‑change: “specified research or experimental expenditures” must be amortized:
    • 5 years for US R&D, 15 years for foreign R&D.
    • Software development is explicitly deemed R&D; most dev labor now becomes capitalized, not immediately deductible.
  • Transition effect: companies went from deducting 100% to deducting only ~10–20% in year one, with the rest spread over later years.

Cash‑flow mechanics and who gets hurt

  • Several concrete examples show how a company can have zero (or negative) cash profit but be taxed as if it were strongly profitable, because only a fraction of dev salaries is deductible in the current year.
  • In steady state with flat headcount, total deductions over time are similar; the real costs are:
    • Time value of money (you’re effectively lending the IRS cash at 0%).
    • A multi‑year “tax spike” during the transition and during rapid growth.
  • Consensus in the thread:
    • Big, stable, cash‑rich firms (FAANG‑type) are affected but can absorb it; many were already capitalizing dev work.
    • Small, thin‑margin or modestly profitable software firms, and fast‑growing startups, are hit hardest; some report tax bills quadrupling, hiring freezes, or shutdowns.

Is this good policy? Competing views

  • One side: this simply closes a generous R&D loophole; software is a capital asset like a factory, so its creation costs should be amortized; subsidies distort markets and shift burden to taxpayers and non‑R&D firms.
  • Other side: historically, immediate expensing was a deliberate pro‑innovation policy; removing it:
    • Discourages R&D and early revenue, especially in software where code ages quickly and many firms never reach year 5.
    • Entrenches incumbents and weakens the startup ecosystem and open‑source work.

Politics and “time bomb” framing

  • Change came from the 2017 tax act, effective 2022, widely viewed as a budget‑scoring gimmick to offset corporate rate cuts.
  • There is broad bipartisan interest in restoring immediate expensing, but fixes have repeatedly stalled and are now bundled as a temporary rollback inside a larger, controversial tax bill.
  • Some see Section 174 as a deliberate political time bomb and a bargaining chip; others attribute the mess to routine reconciliation games and legislative dysfunction rather than targeted malice.