frankie-tales

Still, no silver bullet

2025-08-24T18:30:00Z

I recently re-read the seminal book by Fred Brooks about software engineering, entitled "The Mythical Man-Month" or MM-M for brevity. Specifically, I read the paper version of the 20th anniversary, which was revised and reprinted in 1995, after the first edition of 1975. I did that on purpose, firstly because it is always a fantastic read, and secondly to understand how much of its contents is still valid today, exactly thirty years later since its last revision.

Fred missed in 2022; otherwise, it would still be interesting to know his thinking nowadays after the LLMs boom and the birth of the AIAD (AI Aided Development) as a new revolutionary (or often seen as such) tool. Hi, Fred, wherever you are. It is worth mentioning that AI was already taken into consideration by Brooks at the time, even if limited to expert systems and other rule-based variants, which seemed promising and often sold as revolutionary before the mid-90s. A lot of the book's contents remained in the history of software engineering, including the famous Brooks' Law, and the whole book is still an excellent source of inspiration for any management and organization of complex intellectual projects (not necessarily limited to software systems), that heavily includes large teams of individuals.

One of the main theses of the latest book edition is that in the short term of 10 years from its proposition (the original essay was dated 10 years after the first edition of the book), he did not expect a silver bullet. That means no significant technological or managerial development was expected to be able to improve our productivity in programming by one order of magnitude. Ten years later, he confirmed the same idea, even considering exceptional tools like old-generation AI, visual programming, CASE tools, and so on. Is this thesis contradicted in 2025 by the existence of current AIAD tools, including chatbots, agents, and AI-empowered IDEs? My honest idea is no. I mean not now and not for the foreseeable future. The reason is exactly the same as Fred posed at the time. Reducing accidental problems in software creation (what AI is able to do) cannot be confused with the essential problems in software creation: the complexity of defining an articulated task, its analytical specifications, and an algorithmic solution to solve it. First of all, ignore the simplistic case of asking an AI engine to implement a very simple program. Here, the word simple means truly that. If you can specify a request by a whatever large manageable token context and formulate your request in terms of a brief question (let me suppose a question of some dozens of rows), well, that's probably an example of a simple (or dumb) problem. Too few, too easy. We are talking about a whole system that is generally difficult to describe, even in thousands of pages of specifications and documentation, written collectively by large teams of developers, architects, and domain experts.

The hard truth is that most of the real-world information systems out there cannot simply be specified in such a way. We are not able to define an unambiguous and complete enough specification to describe such systems, not to mention being truly able to write a complete and neat documentation of it, including its inner workings and use. We live in a deep illusion about that. The context size to get the required level of details to avoid bugs and ambiguities in specification would be impractical for current and even future tools, as well as for any humans. We would get in any case buggy (i.e., incomplete or misunderstood) results even if the AI engine were able to avoid hallucinations (which is not the case) and had no limitations for context size. The presence of AI hallucinations is only accidental in this regard.

In the current AI tooling, we are simply moving the complexity from the writing of a formal language step by step to using a natural language with a higher level of abstraction to express the problem. The complexity is still there, and it is inherent to the problem. Again, we resolved an accidental difficulty in a creative manner, not different from moving from assembly to using a modern programming language. Now the difficulty has moved elsewhere, but it is still there, and natural language is even more complicated to use compared to formal language. These difficulties translate into multiple refinements and trials to try to be more precise and get sensible answers and code in a continuous iteration. Isn't that so similar to the whole ordinary process of developing a program? In the most simplistic approach, such a process becomes vibe coding, and iteration could tend to infinity, with a forever loop. The smarter programmer for an easy task will do that in a reasonable (limited, hopefully) number of iterations, instead. Is that a significant improvement of one order of magnitude? I think not, as in most cases for the past. As in the case of high-level languages instead of assembly, they improved efficiency in coding as asserted in MM-M, but not by a whole order of magnitude. The AIAD is again another helper to solve accidental difficulties. The problem and all its complexity are still there. Thinking that we found the silver bullet is again (and again) an illusion or pure marketing.

So why do many CEOs insist on predicting a bright yet unlikely future of AI agents instead of having developers create applications? Brooks already wrote about that: there is a profound confusion in exchanging months and men, and an excess in optimism when approaching software development, even among techies, but that becomes paroxysmal among managers. None can seriously provide even a decent and reasonable evaluation of development time starting from incomplete, ambiguous, or vague specifications: the same simply happens systematically in overestimating the capabilities of current AI tools.

So what? AIAD is simply yet another tool among those available to developers, but the management problem of dominating complex projects is still there, with all its inherent difficulties. And the possibility to use natural language instead of a high-level formal one is only an apparent simplification of the process. It looks more familiar and easier, but it is also much more ambiguous, and the so-called prompt engineering is again a pure optimistic illusion, an euristhic approach to try to overcome our totally insufficient capabilities of dominating nuances and semantics.

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.