First, the issues you describe affect only unclassified public-facing web services, not internal DoD internet services used for actual military operations. DoD has its own CA, the public keys for which are not installed on any OS by default, but anyone can find and install the certs from DISA easily enough. Meaning, the affected sites and services are almost entirely ones not used by members of the military for operational purposes. That approach works for internal DoD sites and services where you can expect people to jump through a couple extra hoops for security, but is not acceptable for the general public who aren't going to figure out how to install custom certs on their machine to deal with untrusted cert errors in their browser. That means most DoD web infra is built around their custom PKI, which makes it inappropriate for hosting public sites. Thus anyone operating a public DoD site is in a weird position where they deviate from DoD general standards but also aren't able to follow commercial standard best practices without getting approval for an exception like the one you linked to. Bureaucratically, that can be a real nightmare to navigate, even for experienced DoD website operators, because you are way off the happy path for DoD web security standards.

Second, many DoD sites need to support mTLS for CAC (DoD-issued smartcards) authentication. That requires the site to use the aforementioned non-standard DoD CA certs to validate the client cert from the CAC, which in turn requires that the server's TLS cert be issued by a CA in the same trust chain, which means the entire site will not work for anyone who hasn't jumped through the hoops to install the DoD CA certs. Meaning, any public-facing site has to be entirely segregated from the standard DoD PKI system. For now, that means using commercial certs, which in turn requires a vendor that meets DoD supply chain security requirements.

Third, most of these sites and services run on highly customized, isolated DoD networks that are physically isolated from the internet. There's NIPR (unclassified FOUO), SIPR (classified secret), and JWICS (classified top secret). NIPR can connect to the regular internet, but does so through a limited number of isolated nodes, and SIPR/JWICS are entirely isolated from the public internet. DoD cloud services are often not able to use standard commercial products as a result of the compatibility problems this isolation causes. That puts a heavy burden on the engineers working these problems, because they can't just use whatever standard commercial solutions exist.

Fourth, the DoD has only shifted away from traditional old school on-prem Windows Server hosting for website to cloud-hosting over the past few years. That has required tons of upskilling and retraining for DoD SREs, which has not been happening consistently across the entire enterprise. It also has made it much harder to keep up with the standards in the private sector as support for on-prem has faded, while the assumptions about cloud environments built into many private sector solutions don't hold true for DoD.

Fifth, even with the move to cloud services, the working conditions can be so extraordinarily burdensome and the DoD-specific restrictions so unusual, obscure, poorly documented, and difficult to debug that it dramatically slows down all software development. e.g., engineers may have to log into a jump box via a VDI to then use Jenkins to run a Groovy script to use Terraform to deploy containers to a highly customized version of AWS.

Ultimately, the sites this affects are ones which are lower priority for DoD because they are not operationally relevant, and setting up PKI that can easily service both their internal mTLS requirements and compatibility with commercial standards for public-facing sites and services is not totally straightforward. That said, it is an inexcusable shitshow. Having run CAC-authenticated websites, I can tell you it's insane how much dev time is wasting trying to deal with obscure CAC-related problems, which are extremely difficult to deal with for a variety of technical and bureaucratic reasons.

In extreme cases, that can manifest as autoimmune disease, when overly strong inflammation or other immune responses end up attacking not just foreign pathogens but the person's body itself. As another poster said, inflammation is a blunt instrument. It's a knob that can only be turned up or down, across the entire body. If you turn it down too far, you risk infectious illness. And if you turn it up too far, you risk damage to your organs.

Interestingly, there was a substantial increase in the incidence of autoimmune diseases in Europe in the generations following the Black Death, probably because people with excessively strong immune responses were more likely to survive exposure to plague bacteria. Celiacs or MS will kill someone much, much more slowly than bubonic plague will, so a disproportionate number of people with those or similar autoimmune disorders were able to survive to pass on their genes.

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.