Enterprise software systems, or how diamonds never came from s*it

2025-02-23T15:00:00Z

Some time ago, I eventually listened on YouTube to a year-old interview by Guido Penta with Salvatore Sanfilippo (aka Antirez) about the art of development in the current age. I agree with some points, specifically that in many cases, multiple developers work for their whole work life on boring/marginal activities. One of them, IMHO, is the entire front-end effort in developing web-based applications, a development task that nowadays could be broadly and proficiently managed mainly via AI to reduce human intervention to minimal parts and architectures.

Many mid-to-large-size companies aim to produce and maintain software systems thanks to interchangeable average-level personnel who work on well-known and established tools. Too many creative and original approaches are banned from the start. The average developer must represent a little gear in the whole system, nothing too essential for creating and maintaining the products and services. Let me call it the standardization of the development process, which is conceptually an entirely creative process and, therefore, original. Indeed, the core goal is moving from crafting to industrial design, which does not necessarily imply achieving better quality but other objectives, such as the right timing to market, cost optimizations, etc.

The result can be a mass of frustrated professionals who have very few alternatives but to escape and continuously try to find better companies. Passionate people find a compensation valve in FOSS projects for being paid to work on lousy legacy code bases for their entire professional lives, company after company.

In some regards, it is not that different if you work in IT for the academic domain, where often the only code you write is a proof-of-concept, just to perform some quick-and-dirty experiments before relegating it to the trash and moving on to the next project. Thesauring the code developed in years, making it better, clean, and helpful for a reference community, and building on it a whole ecosystem is not so common in many academic areas. Often, the code per se is pure garbage for intrinsic quality, often produced by students who are only around to learn and escape with a degree and minimal effort. Sometimes, this is done by scholars whose main interests and backgrounds are not in coding. The big difference is that in the enterprise world, there is no trash, only do-not-touch repositories with (almost or pretending so) working code to preserve.

Very few are interested in perfect coding, solving stimulating problems or providing new conputng approaches.

Unfortunately, the average code quality is not the only problem based on my experience. As a typical user and citizen, I often have to use digital systems of public administrations that seem created by a group of drunk monkeys, with a terrible UX and that often, instead of genuinely simplifying the tasks, overcomplicate them and require more time and manual work that any respectable user could solve alone with a piece of paper and a pen. Sometimes, the digital system solves the wrong problem (sort of finger-and-moon syndrome), the documentation and the systems are completely disconnected, or things change for the worse over time, and so on.

During my professional life, I had some enterprise consulting periods, and I experienced precisely the main reason for that, IMHO. Inevitably, developers and end-users are totally and definitively disconnected during the development and the lifetime of software systems. Even if, in theory, the enterprise assigns internal human resources for analysis and design, those people have literally no idea of what they are dealing with because they are not the true average end-users. The results are systems and subsystems developed based on partially incomplete and often missing or misleading specifications. Developers with deadlines have to invent all the missing parts and work with their own capacity (if any) to understand the application domain and cross their fingers. Literally, the whole agile design, in many cases, is based on a trial-and-error basis, but with no one who is genuinely able to say if the result makes sense for the end-users and the processes already adopted in the target customer enterprise or user community — a sort of dialogue between blind and deaf-mutes. Try to imagine the results when developers are temporary workers whose only main goal in life is escaping from that bad-ass consulting company.

In the case of public administration digital services, the final result is a big f*k! exclamation when the end-user (you!) discovers the final UX of the new system during every new release. Just after learning the intricacies and idiosyncrasies of the system in version N, you find out that version N+1 is even worse, only with a different set of idiosyncratic features to learn to dive again and again.

About the enterprise, the bigger the company is, the bigger the disconnection between developers and the end-users, with a unique taste for autoreferral management of new features and bugs. If you connect this problem with strictly deadline-based development, reduced attention to code quality, and demotivation of the developer teams, you get a lethal combination for the final results.

FOSS development was born to re-connect developers and users in a single well-linked community, where the developers can have a direct idea of what features make sense, what changes are due, what the main bugs are, and so on. FOSS developers are often passionate people who pay great attention to details and code quality, with no deadlines but those dictated by the general quality of the result.

Enterprises nowadays have often adopted FOSS as a mainstream license but never truly gained the unified-community-driven spirit. The result is, again and still, the usual sh*t. No diamonds around, damn it.

frankie-tales

Enterprise software systems, or how diamonds never came from s*it