The Rise of Slop (In Tech)

The Simulacrum of Utility

Within the past year or so, a new term has gained prominence within social media: slop. Slop is not merely that which is done sloppily and poorly; it is that which embodies sloppiness itself; it is poor quality, deracinates, degrades, and traps its beholders in the swamp of pervasive mediocrity and cheapness, perpetuating itself by staining and ruining everything around it, by virtue of it being so ubiquitous and convenient.

The first time I saw the term slop used was in the context of of goyslop, as a term to refer to popular fast food chains. The food, while generally and obviously unhealthy, can actually be tasty, yet not in the same manner in which a delicacy is tasty: the tastiness of slop comes from its convenience and familiarity. It appeals to a certain peasant-like sensibility (hence goylsop). Slop makes one feel disgust and shame, debasing its consumer while simultaneously providing the sensation of comfort, frugality, and convenience. Consumers of slop are aware that the product is subpar; it is neither nutritious nor effective, nor does it provide a great degree of enjoyment; yet, it embodies the aesthetic of utility, or the path of least resistance.

Embracing the slop is a way to free up time and resources for other, more valuable pursuits. Though it provokes disdain and scorn, it cannot truly be dismissed as pure evil because it satisfied a certain need. And thus, the slop proliferates, for there is no true strong argument against it, save for the very need and utility it serves. To decry slop is to be a perfectionist autist, to be a snob, to be a classist. Denouncing slop is impolite, impractical, and impotent - remember, some people don’t have the time or the money to obtain anything better; so you better check your privilege!

The Proliferation of Slop

Slop proliferates itself through the slop mindset; which is that all things must be done quickly and expediently; the perfect is always beaten by the sufficient; the thinker by the doer. Platonic Ideals and Aristotlean Forms have no power or dominion over the conveniently located and modestly priced BigMac. The historic American can-do attitude has been transformed into a must-do attitude. We still reserve space in our minds for excellence, but merely as an impractical ideal and not a reality worth pursuing. Perfection is praiseworthy and noble, but when managing priorities and thinking practically, it is always preferrable for someone else to autistically strive towards perfection - as for us mortals, we must orient ourselves towards that which is attainable at the present, and not that which is imaginable for the future.

Slop increasingly becomes part of our reality; cardboard-textured fast food; badly produced movies where the plot is a copy of a previous feature and the necessary motifs of queer persons of color become the protagonists; hundreds of web applications which barely function but somehow serve their purpose; pop music which lacks creativity; shoddily produced tiktok videos informing us of the workings of reality; cheap trinkets from the orient which retain their carcinogen odor and are produced by underage industrial slaves; quickly produced online skits and articles conveying no true emotion or value - clickbait - but sufficient as a time filler.

There is also AI slop - entire web pages composed of ChatGPT-generated texts, being moderately informative but painfully artificial. The reader is subconsciously aware that this is low effort and low quality. AI-generated images, which at first were a novelty to bring shock to its viewers, but have now proliferated to such a great extent that any true shock value is lost.

While products of low quality have always existed, those products typically at least exhibited the appearance of effort, and customers too usually had a clear distinction of higher quality of alternatives. Perhaps, from an economic perspective, this may have been due to the general high barrier of entry to produce something even of poor quality - and thus, the gap between poor and high quality was not as large as the gap between poor quality and nothing at all. Slop, on the other hand, makes no such attempt: They know that we know that they know: it’s all slop - so why bother?

As more and more slop enters our daily lives, all other elements of perfection begin to slowly slip away. Slop begets more slop, and it becomes increasingly difficult to demand and justify perfection when this perfection itself will just be invaded by more slop. Slop is the expedient, quick, and ever pervasive, while the perfect is the deliberate, time-laden, and difficult to cultivate.

Techslop

Slop has also proliferated its way into the tech industry. The production of software as a discreet product has rapidly declined over the past decade. Previously, companies would sell software under license, with the intent of being maintained by the customers during normal operation, and serviced by support in times of need. However, as consumers generally found it challenging to hire competent staff to maintain these on-prem services, and because licensing costs were generally quite high, vendors sought to provide an alternative - one which would make their products more appealing to consumers by reducing the maintenance burden. Rather than releasing software to be installed and deployed by the consumer, access to software itself would be sold; the software executable itself would be completely maintained, run, and executed - hosted - by the vendor. The concept of Software As A Service, or SAAS, was born.

In the SAAS model, the burden of maintenance, installation, and deployment are all undertaken by the vendor; all the consumer needs to do is cobble up some code to interface with this service. Scalability also becomes less of a concern, since these SAAS are hosted on cloud platforms instead of enterprise datacenters. If the service is ever stretched to maximum capacity, it can simply be scaled with ease - the only cost being the additional cloud resources used, all being managed by the vendor. This was considered a marked improvement over the legacy model, in which the consumer would need to dedicated significant time, manpower, and funds - purchasing and provisioning additional hardware.

At first glance, the new model would appear to be a net benefit: consumers can now dedicate more resources to their own business model and less time focusing on the software being used - which from a business standpoint is nothing more than a tool. However, despite the ostensible corporate benefits, the quality of software declined. In the legacy model, software as a product was designed to be a complete and robust system, taking into account the many different potential use cases - with various combinations of operating systems and environments. APIs too would be designed for speed and optimization - with an installable library or executable offering many different forms of API calls which allowed consumers to cleverly select the usage model that was optimal for their specific deployment. In the process of designing a product for a multitude of platforms and APIs, engineers would often find flaws - either in logic or in efficiency - and consistently optimize and redesign at the ground level until an ideal was reached. Engineers would also need to concern themselves about future extensibility, maintainability, and the general ease of installment and deployment. The software systems of old were anything but slop, they were engineering masterpieces which stood the test of time - with codebases being maintained and having a lifetime of 5-10 years on average - if not more, when properly designed.

But with SAAS, software is no longer a true product of engineering, but a glued-together frankenstein that is designed to function only to the extent that the company is able to retain customers. SAAS offerings typically operate over inefficient and high latency web-based APIs which adopt a one-size-fits-all approach, with any complaints against lost efficiency and optimization being addressed as the cost of quick development models; the seemingly infinite amount of processing power and network speed also eliminates the need for most optimizations, they claim.

Many, of not most modern SAAS services depend on other SAAS themselves, all with dubious guarantees of stability and performance. The goal is to make things easier for the consumer - instead of having to write code which connects to two separate services, the customer only needs to write code for one; certainly efficiency and optimization is further lost here, but the tradeoff is seen as worthwhile. Processing power is infinite and network latency is close to zero, it is claimed.

There is no longer any incentive to write anything of quality, because any well-engineered software component will itself, merely communicate with other slop. Is spending several weeks optimizing for a 20% performance boost truly required? If the constituent services are not optimized, and if the customer doesn’t expect high performance, but merely sufficient performance, then is speed really an issue? Will long-term maintainability really matter if the software dependencies in use will themselves likely not be maintained for very long?

The slopification of the software world made it easy for enterprises to get more done with less, but it also allowed all sorts of startups to spring up which provided the illusion of a product without actually having any. A nicely designed webpage powered by AI and a fancy powerpoint presentation is typically all that is required to convince guru investors that there is a future market. What would previously take almost a year to prototype can now be done within a matter of weeks. It won’t be the same quality, but that doesn’t matter - the point is to sell, sell, and sell! - it will eventually be someone else’s problem and not theirs; they can even blame it on dependent services - who is really responsible? Nobody knows!

Slop Cathedrals, EHC Bazaars

Eric S. Raymond (http://www.catb.org/~esr; also on X as @ esrtweet) wrote his seminal essay, The Cathedral and the Bazaar in the late 1990s. In this essay, he argues against the cathedral model of development and in favor of the Bazaar. In the Cathedral model, software design and development is a top-down process, with many supposed gurus and experts dictating how the end product should look like. The general public, or the wider community only ends up being involved in the development process at the point of product release. This model is called The Cathedral because it requires collusion of a privileged few, who are vested with the knowledge, expertise, and authority of the software being designed. The Cathedral model is contrasted with the Bazaar model - in which the development process is an open one, with all having the ability to observe and comment - and at times even contribute - to the final product.

In the essay, Raymond argues that the Bazaar model is superior because of the inherently open, collaborative, and participatory nature of the entire community. Both users and engineers feel they are part of something, have the ability to comment, and are given the feeling that they can impact the direction of the product if there exists enough motivation and popular support to do so. The increased amount of community participation means that more people make themselves available for voluntary testing and are more inclined to provide constructive feedback, seeing themselves not only as consumers or employees, but also as investors. The Bazaar model is self-disciplining, self-filtering, and self selecting. It inherently becomes meritocratic, with the brightest engineers taking leadership roles, and less experienced engineers seeing this as an opportunity to learn and contribute in other ways. As a project attracts interest - usually by a sound technical idea combined with a roughly implemented proof of concept, engineer enthusiasts will flock to contribute, finding potential in it; willing to dedicate their time to test, fix, and even contribute code, if it is a project they find useful.

While The Cathedral and the Bazaar was intended as a discussion of the OSS/FOSS (Free/Open Source Software) world, many of its principles can be applied as general sociological concepts even when software is not strictly open. Roughly speaking, a Cathedral model is one in which a ready-made product is handed down by ecclessiastical dictate to its user base, often with very well defined usage constraints and guiding principles, while the Bazaar model is one in which a company always has its ear open to suggestions and improvements, and is willing to hear input from any user or enthusiast within the community at large.

However, the SAAS landscape is a model that can properly be called the Slop Cathedral. SAAS products offer very little for a user to be enthusiastic about - its value proposition is being an affordable and quickly made tool of convenience. Enthusiasm is besides the point, since the SAAS doesn’t actually do anything - instead, it simply reduces the user’s workload by employing a few quick principles. SAAS is generally specialized into a specific niche, with the aim not being attracting new users to a new development model, but trying to fit its service within existing use cases, as a way to gain more of the market share by means of convincing users that they can make an already established process even easier. Because SAAS doesn’t particularly offer robust and optimizable APIs, there is not much which inspires a user to try and offer suggestions. The user is well aware of the SAAS as a semi-disposable glued-together cobbled-up frankenstein; any improvements or modifications are requested not out of a desire of perfection, but as a critical matter of usability; when the product fails to meet even its most basic use claim.

Because SAAS is not a downloadable product, it cannot truly be debugged by a user; there are only inputs and outputs, but no operating environment, no visible memory, no other dimensions by which a user can interact with this product. Quite simply, SAAS is cumbersome, uninspiring, and closed off.

Slop Engineers for a Slop Product

Good engineers do not enjoy working with slop. Engineers prefer to imagine themselves working on something great, something that will stand the test of time, and something they will be acknowledged for. But slop is not an engineering effort, it’s a marketing effort. There are not many distinctions in the performance characteristics or featuresets of various product on the market today. Many flavors of the same thing exist and are readily available, the user just needs to figure out which one gives him the best vibe, and which one seems best taylored to his use case.

Larry Wall mentions the three virtues of a great engineer

1. Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.

2. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.

3. Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.

All these three virtues lend themselves well to stable and durable software products and utilities. The internal tools of SAAS companies are disposable; in fact, companies actively discourage against writing small tools and utilities for long term use, and why should they? Internal APIs are constantly changing (because they can), and so are their underlying platforms (because they can); after all, because the product is not downloadable, but rather offered as a service, as long as the public-facing API remains the same, there is no limit to the amount of internal changes that can be made under the hood. While this may be perceived as flexibility, it actually also brings about reduced internal stability. But this lack of stability leaves engineers demotivated to actually develop anything of quality - anything which goes above and beyond the requirements given to them. An engineer can write an internal tool today, and tomorrow it may no longer function.

Slop engineers happily fill these roles. They are not very enthusiastic about the product they’re working on; they merely receive a set of instructions to bind two services together- and they do it. Simple, compliant, without much technical discussion; no questions asked: They lack the required hubris which great engineers possess. Slop engineers actually enjoy writing code, because in the mind of those engineers, more code is more productivity; whereas good engineers spend most of their time thinking about what code they can remove. But for the middling engineer, the more busy they feel doing something, the more important and accomplished their psyche and ego becomes: they lack the virtue of laziness. Finally, slop engineers, generally being very mediocre minds, have absolutely no problem waiting for a computer to accomplish its task, or repeatedly testing things again and again, because this fills their time: slop engineers are patient, accepting the technical reality rather than designing to change it; they lack the virtue of impatience.

Companies are specifically on the lookout for mediocre, slop-oriented engineers who will shut up and do what they’re told, remain loyal and obedient to their managers, and won’t question existing corporate practices. They’re also looking to pay them as little as possible.

QA Testslop

Another element of slop that has been introduced into the industry is that of testing. In the premodern era, engineers who wrote their code would also write appropriate tests for it. This process was generally time consuming and not very glorious, but it ensured a quality product. Engineers would be forced to think about the different environments in which their software would be used, and different input/error conditions which might arise - and would write tests for all of them. Nobody liked writing tests, but it was a fact of engineering life.

With self-authored testing, it was also understood that the engineer himself was responsible for the quality of the product; while very large corporations had dedicated testing departments, those departments would focus more on large-scale testing, stress testing, or load testing - but the general idea of unit testing - ensuring that the product functions as advertised - was left to the engineer himself.

Some firms sometimes often opted to go the open source route, employing the aforementioned bazaar model for getting as many eyes on the codebase as possible, allowing an increase in quality.

But testing has now undergone a process of bureaucratization. While engineers still do write at least some tests, most organizations have large departments (often staffed by cheap labor - either H-1B or offshore) who are responsible for running and designing more tests, to increase quality. The initial motivation was a good one - free up the engineers’ precious and expensive time to work on more interesting things, rather than go through the boring routine of writing tests. This approach however, was inherently problematic: Engineers - the designers themselves - understood the weak links within their programs, while Indian code monkeys did not. A QA team of 10 people might be able to write “1 Million Tests”, but how many of those tests actually cover the stress points and weak links of the program? Most of these are just tests for testing’s sake and not much beyond that.

But decision makers love to see ‘1M tests executed in 50 hours’ rather than ‘50 tests executed in 20 seconds’, even though the latter may be superior to the former in many ways - but because moar is better, the teststlop QA bureaucracy firmly entrenched itself as part of the tech landscape, portraying itself as the guardians of stability and reliability. Its existence is not entirely futile, of course - of those 1M tests, it certainly stands to reason that at least some of them would reveal something useful about the program. But even in cases where tests reveal problems, it is often either because the testing scenarios are unrealistic, or the tests themselves are buggy - remember, incompetence, bad design, and bad implementation always leads to a bad outcome. Badly designed or non-deterministic tests may cost just as much engineering time as having the engineer write the tests in the first place; but from a corporate perspective, reactive is always better than proactive - It’s far easier to justify the number of bugs found and solved by ‘intense testing’ - and thus justifying the resources spent on QA, than the number of bugs avoided by ‘careful development practices’ - the resources spent on extended development time.

The QA beureaucracy is here to stay, however. Removing or reforming it is tantamount to releasing an ‘unstable product’ — though it stands to wonder whether the amount of bugs has really gone down in software released by firms with large QA departments. This doesn’t seem to be the case.

Support, Evangelization, and more slop

In addition to the testslop mentioned above, the tech industry now has a proliferation of supportslop - meaning a large tech support team to provide services to customers. The American marketplace loves services: It gives them peace of mind that someone is able to quickly answer their questions and address their concerns. Historically, startups had a fairly competent support staff, most of them being former engineers themselves, or engineers in training. But as with everything, support has now become a specialized role, with the aim of spending less and less of the engineers’ (precious $) time doing non-R&D-related tasks.

Thus, the support bureaucracy was created; different escalation strategies formalized, different issue tracking systems developed, all with the supposed aim of making the company more efficient (and using less of the expensive engineering time) by hiring more dedicated personnel for specific tasks. However, as a result of support engineers being more and more specialized and more removed from the engineering process itself, they faced increasing difficulty in solving all but the most basic issues at hand; spending more time trying to debug and reproduce issues (and still, at the end, resorting to nagging the precious engineers). Of course, as support engineers were increasingly bogged down, more support staff (and their managerial supervision) had to be contracted.

Engineers were also discouraged from answering common questions on support forums such as Stack Overflow or Reddit. Special evangelists were recruited for this purpose, to provide a positive spin and give canned, generic responses directing users over to corporate documentation (often authored by yet another team).

Engineers also were discouraged from writing anything but the most basic API-level documentation; special teams were contracted to write how-to guides and usage instructions - sometimes out of sync with how the engineers themselves imagined the products to be. Documentation in most cases continues to be poor and badly written, despite being delegated to specialized teams.

The Brahmification of Engineers

The industry practices which created specialized roles for all aspects of the software development lifecycle eventually led to a kind of de-facto caste system. At the top of the caste were the Brahmin engineers.

I am told that in India, the stratifying effects of the caste system led to a degeneration and corruption within the Brahmins. Having been removed and distanced from performing anything but their sacred priestly duties for hundreds, if not thousands of years, the Brahmin caste became detached from reality, developing an arrogant attitude while being ultimately useless at the same time. They dictated, but in most cases did not actually control society; they merely reaped its rewards while perpetuating doctrines that consisted of more corrupt self-aggrandizement and flattery than anything else. The respect for the Brahmin caste came to be not because of their nobility or functions they performed, but because of the perceived sanctity of their station - which they fulfilled rather poorly.

In the tech world too, engineers have become more and more isolated from the actual users of their own products. In the past, engineers would interact directly with customers on support forums, perform testing, and write their own documentation; but now, all these tasks are delegated to discreet and specialized teams. This shift is not without justification, and has to do with the degradation of quality and skill within the tech industry as a whole.

Over the past two decades, software engineering has been transformed from a relatively small group of well educated, competent, and motivated professionals into a global phenomenon and a default career choice. The bar to learning software engineering has been greatly lowered while the social and financial incentives have been greatly increased. It now far easier to begin programming in one of the many popular languages, most of it can be done by simply opening a webpage or downloading a simple program, rather than installing a set of tools or a new operating system. During the 2000s and 2010s, many were promised a lucrative career in the corporate landscape of the future - they just had to learn to code. Third worlders too, especially in India, envisioned themselves creating their own tech industry, supplementing or even competing with the West.

But as with the mass popularization of anything, its overall quality goes down. While the software communities of old were composed of competent individuals who had a sense of shame in asking dumb questions and who wished to be seen as competent and respected, the newer crop of ‘engineers’ (if we can even call them that, and a good deal of them from the third world) now post the most basic questions on forums, the answers to which can easily be found on Google.

Programming technologies have become easier and easier to use, allowing people of lesser competence and intelligence to employ them in a corporate setting, and allowing corporations to hire less and less talented engineers. In a sense, the software community itself has turned into slop. To give one example, Stack Overflow used to be a Q&A site which was strictly regulated for quality; now it has become a place for dimwitted college students to receive help with their homework, with questions often appearing in the classic ESL ‘style’. While the moderation team still tries to keep the site clean, the large volume of low quality questions is just too high.

Engineers, now receiving questions - not from enthusiastic and intelligent users seeking to contribute, but middling morons unable to read basic documentation - have naturally become less enthusiastic about answering them. One can only answer “saar plz program no work, it crash when i run. it show ERROR. how fix????” so many times before feeling existential angst at the user’s incompetent laziness (to be distinguished from the competent laziness described above).

In light of this, it becomes easy to see how the software caste system was formed. Intelligent people are not drawn into the lower casts; in fact, anyone of any mental fortitude will inevitably go insane having to deal with the high volume of - not just uneducated and uninformed - but maliciously incompetent users. Instead, the corporate retards are pitted against the conusmer retards, and exist by means of symbiosis.

In most aspects, a great deal of software expansion and ‘innovation’ is not outwards - to solve new problems, nor is it inwards - to solve existing problems in a more efficient and optimized manner, but rather downwards - to allow more and more people to solve existing problems, but with a reduced skillset and competency; allowing slop engineering to become even more widespread.

Will Slop Die?

Slop is inherently an unsustainable model, because it just draws and attracts more slop - or in the technical world - more ephemeral processes and ‘specialists’ which do little to nothing. To C-levels and managers, they appear to be productive, because if there’s anything techslop knows how to do, it’s create productivity metrics for itself, which it so conveniently manages to satisfy.

But how do we kill it? I’m not sure we can. Ultimately, the slop will cave in on its spineless self; the market will become so saturated with slop products that market shares will increasingly go down. Maybe there’s someone out there with a lot of money to spend, who’s willing to flood the market with a high quality alternative which will but all the slopshops out of business (Elon?); but it seems like much of it is here to stay.

With the proliferation of AI, making slop just became a whole lot easier. In a short time, we will have AIs generating slop at a rate faster than any human being. Maybe at that point, the CEOs, the VCs, and the tech gurus will realize the necessity of shifting from a model of expediency to one of excellence. Until then, the AI slopgap is to be filled with yet more H-1B sloppers.