Brooke Harrington (one of the professors from the OP article) has an excellent book on the topic, called Offshore.
1,833 karma · joined January 15, 2016
I posted about this on Reddit the other day. https://www.reddit.com/r/Economics/comments/1l3lo7j/the_hidd...
> Yeah, it's pretty much completely insane. Although in your example I think you accidentally picked numbers that actually work out precisely to zero dollars in taxable income. The company (if US-based) would have zero taxable income in the first year because they can deduct 1/5th of the salaries (because there is a five year amortization for US companies, and 15 year for foreign companies), so they would have $1m in gross income and $1m in deductions resulting in $0 in taxable income. But you can tweak the numbers a bit to get the result you intended, e.g., $1m in revenue and $2.5m in salary would result in $500,000 additional taxable income under the TCJA's version of Section 174 over the previous version of the code, even though in reality the company operated at a net loss. (edit, just looked this up and actually the amortization is dated from the midyear of the tax year in which the expense is incurred, which is also just fucking bonkers, but that means I was incorrect and your example does yield a taxable income, because the first year in your example would have $500k in deductions rather than the full 20% of the $5m expense, resulting in $500k taxable profit)
> All of which means that we treat R&D salaries less favorably than ordinary salaries, which are fully deductible in the year they are incurred. So our tax code now not only fails to incentivize R&D as under the previous R&D tax credit regime, it actively treats R&D employee salaries worse than non-R&D salaries. Even though R&D jobs are generally the highly skilled, well compensated, white collar careers we want to keep in this country.
> Section 174 also specifically designates all software development as R&D, so there's no way to develop software while claiming it is not R&D. I'm sure accountants have been jumping through hoops in their efforts to reclassify other kinds of product development jobs as not R&D, which is the exact opposite of what R&D tax studies used to do, which was to label as much employee compensation as R&D expenses as possible, because §174 and the related, intersecting provisions of §41 (the R&D tax credit itself), treated R&D salaries more favorably than other salaries. To a certain extent, the OP article understated how much of a swing this revision to the tax code is. It isn't just that we are treating R&D salaries worse than we used to, but that we are treating them even worse than we treat other kinds of salaries. Which is bizarre in a world where the policy objective is to retain R&D jobs in the US.
> The purpose of capitalization is to match expenses to benefits over multiple tax years. So that the tax payer can't take a huge tax deduction up front to generate an economically fictional loss in the short term on an asset that will generate income over the many years. Amortization forces them to deduct the expense of the asset over time as the benefit accrues over time.
> This model is a poor fit for software. Construction workers produce an asset with a generally predictable and known useful lifetime and long-term stable value that is independent of the business. You can always sell a building.
> Software, however, does not generally create value for very long if it is not subject to continuous development and improvement. It also decays very rapidly when not maintained (e.g. security patches), yet there is no distinction in the tax code between new development and production support/maintenance software development. Nor would any such distinction make any sense in reality, because unlike a physical asset software is subject to continuous change and there is little distinction between adding new features and maintaining existing features. This approach to capitalizing salaries contrasts with other capitalized assets like buildings, where most ordinary maintenance costs are deducted in the current year, not capitalized.
> The value of software can be much harder to predict than other capitalized assets. Both in terms of the demand, but also in terms of the technical capability to deliver the desired product. Which is why it's considered R&D in the first place: there is inherent technical risk in many if not most software projects which is not present in other kinds of economic activities that produce capitalized assets.
> Software is often so specialized that it cannot be sold on to a third-party without selling the entire business around the software, including existing customers, distribution and sales channels, and supporting software engineering staff. It's not a liquid, fungible, alienable asset the way other capitalized assets typically are. There is no real market for the source code to Reddit, for example, because there is nothing technically special about Reddit. The company's value derives from the user base, the community, and the data, not anything particularly special about its software.
> The tax code also confuses the output of the software development process with the value software can generate. Software developers produce code. Some of that code is valuable, much is not. Unlike with other capitalized assets, you can't know in advance whether the software you produce actually works 100% of the time, even with robust testing and QA. Whereas you can be quite certain that a building will continue to function as a building if it is built correctly. Many software engineers actually regard code as a liability rather than an asset. The more you have to maintain, the more work you have to do to maintain the code base and the harder it is to add new features or debug issues with existing features. So if you can deliver the same capability to your customers with less code, then that is preferable. Which is to say, the output of the software development process is much more loosely tied to predictable economic value than other capitalized assets.
> Software is also frequently delivered as a service, which highlights the inanity of treating software as a fixed, long-term asset. The team maintaining a SaaS will handle day-to-day site reliability engineering work, which is never a stable output but needs to be constantly tweaked to match actual usage patterns.
> Last, and this is implicit in much of the above, but unlike other capitalized assets, software is never really complete. There are always more features, more optimizations, more bug fixes. Software development is never steady state. Either the software isn't being developed actively and quickly loses nearly all value due to code rot, or it is being actively maintained and improved and is producing value. Buildings don't stop functioning as buildings when you stop paying the construction workers. Thus, software development does not produce a long-term fixed asset but rather is a continuous service delivery process, where the revenue produced in any given year was produced by the same year expenses to maintain the software. Thus, software expenses and revenues are mostly naturally aligned in a single tax year, and therefore software is not suitable for amortization.
> Of course, the air traffic controllers didn't build the runway, and the construction crew don't direct air traffic, so the whole situation is much less ambiguous.
That is precisely why those salaries are NOT capex
This actually understates the issue slightly. The amortization is calculated from the midpoint of the first tax year, so actually you only take 10% in the first year. Meaning it takes six years to get back to square one. In your example, you would only capitalize $20k in the first year, $40k for the subsequent four years, and then another $20k in the final year.
For many years, it was popular (particularly in revisionist circles) almost entirely to deny individual agency and to rely instead exclusively on systemic arguments which highlighted the power of geography, ecology, culture, technology, and other complex systems to shape human events. That revisionist approach emerged partially in reaction to the near universal overreliance of prior generations of historians on the so-called "Great Man" theory of history, which assumes events are largely attributable to the decisions of a select group of politically powerful individuals. Nearly all of those individuals happened to be white, male, and wealthy, and thus Great Man history suffered not only from blindness to systemic factors that can shape events, but also to the experiences, contributions, and agency of anyone who was not rich, not white, not a man, or even simply not politically powerful enough to count. In other words, they ignore nearly everyone who has ever lived.
Although academic history has long since moved away from the Great Man theory, it remains a popular trope of low quality popular history books, and increasingly it has become clear that purely systemic, revisionist approaches with no consideration for the effects of individual actors are also inadequate to explain historical events.
Sometimes systems are more powerful than people, and no amount of good will or effort is going to fix a problem. The Vikings abandoned Greenland during the Little Ice Age because they had no way of controlling the climate or adapting efficiently to the changes. The climate system was more powerful than any individual Norse settler or group of settlers could ever hope to be.
Sometimes systems are weaker than people, and leaders can bend them to their will. After nearly 1000 years of independence from secular authority and mostly uncontested religious domination in England, the Catholic Church in the 16th century formed an incredibly powerful institutional system of religious control built on vast endowments of land. It was by and large extremely popular with the common people and historically served a critical role in bolstering the king's position by promoting a respect for hierarchy that naturally encompassed both their own elevated status as priests and the position of secular authoritarian rulers, who ruled as God's representative on Earth. Despite the Church's enduring local popularity, its immense wealth, its deep connections with the broader Christian world, and the powerful hold fear of excommunication and damnation had on most Christians, King Henry VIII managed to completely transform the institutional, legal, and property-managing system of the medieval English Catholic Church, sundering it entirely from Rome, depriving it of essentially all of its land holdings, and subordinating its institutions entirely to royal authority. And he accomplished this in a shockingly short period of time, only around a decade.
Why did Henry decide to throw his lot in with the Reformation? Was it because he saw the injustice of monks, priests, and friars siphoning off so much of his subjects' wealth to Rome simply to subsidize the already luxurious and decidedly un-Christian lifestyle enjoyed by the pope? Not at all, in fact in the years before his marriage to Katherine of Aragon soured, he wrote a book defending the pope, who promptly named the king Defender of the Faith in gratitude and recognition of his scholastic achievement. Did Henry instead recognize an opportunity to enrich himself? Probably not, the evidence suggests he wasn't that savvy about money, but luckily for him, he had Cromwell to take care of the pounds and the pennies. Ultimately, he just needed a divorce. Because if he failed to produce an heir, the danger of civil war would be intolerable, and Katherine was clearly beyond her childbearing years. But the pope wouldn't give him one, and Henry was a raging narcissist willing to burst through any boundary in service of his own ego, even risking his soul to break from Rome.
So individual idiosyncrasies can also affect the course of events, we can't just look at systems, and we can't just look at individuals, we need systems too. The relative influence of each over how a complex institution like a justice system develops is a highly contingent and fact-specific analysis. Sometimes the climate can push winters to be too cold even for the hardiest settlers. Sometimes an entire nation's centuries-long, enduring religious beliefs and ideologies can depend solely on the whims (and lust) of a single egotistical dictator. And sometimes when such a basic function is this messed up, you might actually find that there are indeed a limited number of individuals responsible, and that replacing them with competent or less malicious individuals will actually solve the problem.
That's the trick though, and where the systemic and individual-focused explanatory variables start to bleed into each other. If it is systematically impossible to find good people to staff these institutions, then yes merely swapping out individuals will not fix the situation because by definition you are swapping out bad people for other bad people. However, I seriously doubt that it is impossible to do so in this case, because even if the US justice system is messed up and broken, this is about the most messed up and broken that it gets. I think it's fair to say that 99.999% of the country does not experience systemic justice problems to the same extent as Maverick County, which is why so many people are reacting to this story with justifiable shock. So even assuming ad arguendo that it is systemically impossible to find truly good people to work in law enforcement or the judicial system, we know it's at least possible to find better people than they have in Maverick County.
As anyone following the war in Ukraine closely has long since realized, village names alone are not very useful for identifying where something is in Ukraine. There are just too many places with the same names. e.g., https://en.wikipedia.org/wiki/Mykhailivka
Not in OAuth/OIDC compliant identity providers. As one example, I frequently use + email addresses for testing on auth0-secured apps, where I use the + text to tag a role or some other user attribute that identifies what makes the test account special. eg stult+admin-staging@example.com or stult+user-declined-gdpr-prod@example.com. Each plus variant resolves to its own separate account with its own password (which I do in fact manage via a credential manager), without requiring me to set up multiple full email addresses to simulate multiple users with verified email addresses.
Well sure. Just because they think it's a more effective way to run their company doesn't mean that their understanding of "more effective" isn't equivalent to exercising more control.
> But...like, do you think management actually thinks in these terms?
People are perfectly capable of thinking about things in terms that are inconsistent with their underlying motivations. Dog whistling in politics works and is necessary because explicit racism turns off a substantial part of the population that nevertheless remains open to more indirect forms of racist policy and language. Thus, dropping n bombs morphed into "welfare queens." While such voters may be uncomfortable with outright bigotry, dog whistling rhetoric still appeals to them because on some level they are not entirely comfortable with true racial equality and integration. i.e., they harbor racial animus that motivates racist beliefs.
Similarly, managers and executives may not feel comfortable speaking explicitly in terms of exercising power or control over their employees while still acting out of a subconscious need to exercise that very power or control. Almost certainly organizational leaders do not form a homogenous block here. Some of the leaders proposing these RTO policies are intentionally disguising their true motivations by using indirect language because they know their true beliefs are socially unacceptable and they do not want to incur the social cost of honestly representing their motivations. Others adopt similarly indirect language and comparable positions without being consciously aware of the emotional needs motivating their choices. Still others legitimately believe in their pro-RTO position without necessarily experiencing any ulterior motive.
> because they don't trust workers not to abuse remote work
Lack of trust in their workers is a failure of leadership. Rather than improve their accountability systems so that they can trust their workers more, they impose an extremely unwelcome cost on those employees. I don't see how that is any better than thinking about the problem in terms of raw power dynamics.
> or sometimes because they've bought into some hustle-culture narrative
Hustle culture itself encodes a sense of superiority that serves as emotional and philosophical justification for the power of business leaders over their employees. It's an example of attribute substitution. They don't know how to measure actual merit or hard work, so they measure visible, loosely correlated behaviors. Again, this is a failure of leadership, and a failure to establish systems of accountability that can function in a remote environment.
It is difficult to see any real moral difference between wanting to exercise power for its own sake and imposing uncompensated costs on employees to avoid doing the hard work of being a leader. Especially because an organization that cannot hold employees accountable in a remote environment will be unlikely to do so in the office either. So far, the overwhelming majority of the published data around remote work and the rigorous analyses based on those data strongly suggest RTO policies damage rather than improve productivity. Likely precisely because organizations with poor organizational mechanisms around accountability continue to perform poorly in office, whereas those with strong accountability perform even better remotely.
When leaders propose arguments for a policy that do not actually justify the policy, it makes sense to consider what their ulterior motives might be. Many ambitious leaders possess a deep psychological need to exercise power over others. That's what makes them ambitious. In the absence of any reasonable justification for RTO, it is thus not unreasonable to attribute their position to that need for control rather than accepting the insufficient and unconvincing excuses they explicitly offer for their position.
These days, it's almost trivial to launder via wash trades with the proliferation of online services with effectively zero marginal costs. e.g., setting up a freelancer account and a separate business account on some platform like Upwork and then hiring yourself. So I'd be surprised to see anyone laundering via sale of goods unless they are deeply incompetent or it's an opportunistic scheme of some sort (i.e., they are exploiting a unique opportunity that pops up).
One of my most frequent criticisms of teams responsible for security is that they spend a lot of time telling people what not to do instead of proactively providing them with efficient tools or methods for doing what they want to do.
Also worth mentioning that the scale of the medieval British slave trade was likely small relative to the total populations of either England or Ireland, because it disproportionately consisted of the sale of young women as concubines. Note that there is a difference between the size of the enslaved population and the size of the slave trade. While as much as 30% of the population of Anglo-Saxon England may have been enslaved and the vast majority of those were economic slaves, only a small portion were ever bought or sold on the slave markets, and an even smaller portion sold to the foreign market.
There was simply less demand for purchasing economic slaves because Ireland did not have a robust cash economy for agricultural goods that would have generated the revenue necessary to acquire slaves. That is, acquiring economic slaves for cash only makes sense if those slaves can be used to generate further cash. Concubinage was an exception because in economic terms it is a form of consumption rather than investment. Economic slaves were more likely to be acquired via raiding or conquest, which effectively converts a surplus in defense spending into an economic investment.
Which isn't to say economic slaves weren't bought and sold, just that demand for them was weak and likely the trade only existed because acquiring them was a "free" byproduct for a seller who acquired them while conducting raids aimed at acquiring liquid wealth and potential concubines. As in, a viking group may have raided a village with the specific intent of seizing any valuables and young women, but figured that they might as well take the young men too because they could at least get something in exchange for them. Demand for agricultural economic slaves was low because the productivity of early medieval agricultural workers was extremely low. Once the Christian church turned against concubinage and extra-marital relationships in general, the demand for slaves disappeared, reducing the incentive to raid and thus the incidental production of economic slaves. Which is a corollary of the argument the OP article proposes for the decline in Norman slavery.
Bottom line, a relatively narrow class of wealthy traders and viking raiders in Ireland would have been purchasers in the slave markets, even though the country as a whole wasn't especially wealthy and did not need to be for the slave trade to exist.
[1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...
The same logic does not apply to all ORMs, of course, which do not all benefit from the same quality of professional dev support that EF receives from MS. But that's my main point from above: the correct design decision depends on the context. For services written in other languages with other ORMs or raw SQL, I absolutely will spin up a full Postgres test container because it is indeed trivial (have one running in the background on my laptop right now in fact). It just isn't necessary in the specific context of EntityFramework code.
Anything that has a legal requirement to remain unbiased will also clearly define what counts as bias, e.g. discriminating based on race in hiring like you mention. So there's not just some requirement that a process be "unbiased" in a vague, general, philosophical sense as debated above in this thread. Rather, the definition of bias is tied to specific actions relative to specific categories of people, which can thus potentially be measured and corrected.
More generally in ML, bias means that the training set deviates from the ground truth systematically in some way. Entirely eliminating bias that falls into that broader definition seems like an impossibility for general-purpose LLMs, which cover so much territory where the ground-truth is unknown, debatable, or subject to change over time. For example, if you were to ask an LLM whether governmental debt above a certain percentage of GDP damages growth prospects sufficiently to make the debt not worth taking on, you would not receive an answer that corresponds to a ground truth because there is no consensus in academic economics about what the ground truth is. Or rather you wouldn't be able to know that it corresponds to the ground truth, and it would only be a coincidence if it did.
That ML definition of bias runs against the legal definition where the ground-truth is itself biased. e.g., if you were to develop an algorithm to predict whether a given student will succeed in a collegiate environment, it would almost certainly display racial bias because educational outcomes are themselves racially biased. Thus, an unbiased algorithm in the ML-meaning of the word would actually be extremely biased in the legal sense of the word.
Really, the whole point of science is that claims have to be falsifiable with evidence, which is more or less the opposite of provable. Nothing is ever positively proven in science, hypotheses are only ever falsified, and only hypotheses susceptible to falsification with evidence are scientific. A failure to prove a hypothesis false is the closest we come to establishing a positive scientific truth.
[1] This is typically because the expected outputs are not easily known or specified in advance (e.g., interpolating a 3D wind cube to a higher resolution from lower resolution forecast data) and there isn't much if any experimental data, and collecting such data is expensive because it requires flying expensive aircraft around for long periods of time.