The world of information technology, for all its rapid advancement, often seems to suffer from a peculiar form of amnesia. We are a field that thrives on innovation, yet we frequently find ourselves re-packaging concepts that have been well-established for decades, cloaking them in trendy new terminology. This tendency is not merely a matter of semantics; it speaks to a deeper issue within our culture: a disconnect from the foundational principles that underpin our work. How often have you encountered a "revolutionary" new approach, only to discover it is a slightly modified echo of ideas from the golden age of computing, the fertile period between 1950 and 1980? This era, marked by pioneers like Niklaus Wirth, John Backus, Grace Hopper, Douglas McIlroy, Edsger W. Dijkstra, and many others laid the groundwork for much of what we consider "modern". Yet, a chasm exists between the wisdom of these masters and the contemporary rush to brand every iteration as a groundbreaking breakthrough. The result is a landscape littered with buzzwords, where the core principles of software engineering are obscured by the fog of marketing and the erotic attraction of novelty.
Code-Splitting and the ghost of modular programming
After two intensive weeks, today I resumed my work as a contributor to the W3C Web Sustainability Guidelines (WSG). I like these guidelines, and I believe that all the effort put into this document by my predecessor is outstanding and remarkable. I am so grateful to all the contributors. When I came across the term "code-splitting," my first reaction was, "What is it?" It did not take me long to grasp the idea behind the term, but I was not sure how to apply it in web development. After a quick search, I found that the concept of "code-splitting" is primarily associated with Webpack and modern JavaScript frameworks."Code splitting is the practice of splitting the code a web application depends on — including its own code and any third-party dependencies — into separate bundles that can be loaded independently of each other. This allows an application to load only the code it actually needs at a given point in time, and load other bundles on demand. This approach is used to improve application performance, especially on initial load." (MDN, no date)
Or from Webpack:
"Code splitting is one of the most compelling features of webpack. This feature allows you to split your code into various bundles which can then be loaded on demand or in parallel." (webpack.js.org, no date)
Compelling features? Really? I believe that modularization nowadays is one fundamental principle of the software engineering. Can you really think without it in 2025? At its heart, code-splitting advocates breaking down large, monolithic applications into smaller, manageable segments that can be loaded on demand.
Modular programming is a discipline championed by many software engineers in the 1960s. For example Douglas McIlroy at Bell Labs in the late 1960s, specifically advocated for software components and reusable modules, while presenting "Mass Produced Software Components" at the 1968 NATO Software Engineering Conference.
"The idea of interchangeable parts corresponds roughly to our term 'modularity', and is fitfully respected. The idea of machine tools has an analogue in assembly programs and compilers." (Naur and Randell, 1968)
Wirth was influential in developing programming languages that emphasized modularity, particularly Pascal in the late 1960s and early 1970s. This because modular programming represents one of the fundamental paradigm shifts in software engineering, with its emphasis on dividing, encapsulating, and reusing code, aimed to tackle the very same challenges that code-splitting purports to address.
The principle is timeless: break down complex systems into manageable components, load only what is necessary, and enhance code reuse.
Where Wirth spoke of modules (known as "units") and procedures, modern developers speak of code-splits and bundles. This renaming is not inherently harmful, but it does illustrate a broader trend: a tendency to ignore the rich history of our field in favour of the latest technological buzzword.
Possible reasons behind the reinvention: marketing, ignorance, and ego
Why does the IT industry persist in this cycle of reinvention? Several factors contribute to this phenomenon.
First, there is the undeniable influence of marketing and hype cycles. In a field driven by the pursuit of the next big thing, old ideas are often deemed "legacy" and therefore undesirable: the legacy stigma. So, rebranding allows these ideas to be presented as cutting-edge innovations, attracting attention.
Second, there is a noticeable lack of historical awareness among many developers. With the rapid pace of technological change, there is often little time or curiosity to delve into the history of computing. As a result, many assume they are discovering something new, unaware that their "innovations" are merely rediscoveries.
Finally, there is the human element: ego and the desire to be seen as a revolutionary. Each generation of developers wants to leave its mark creating their own "revolution" often at the expense of building upon the knowledge of those who came before. A strong ego can drive individuals to seek external validation and recognition. The article of NeuroLaunch editorial team (2024) explores the various psychological mechanisms that drive validation-seeking, which can be strongly tied to the ego's desire for recognition and admiration. The article heavily implies that the need to be seen as special or worthy is a significant motivator.
The price of ignorance: redundancy and maintenance burden
The consequences of this constant reinvention are far-reaching. Redundant research and wasted effort are perhaps the most obvious. Instead of building upon existing knowledge, we blindly squander resources rediscovering what has already been established. This leads to inefficient tech cycles, where the same ideas are repeatedly recycled, hindering true innovation. Moreover, ignoring foundational knowledge often leads to poor software design and the accumulation of avoidable maintenance burden. When developers are unaware of the principles that have guided successful software development for decades, they are more likely to make costly mistakes, creating systems that are fragile, difficult to maintain, and prone to failure.
A call to respect the pioneers and learn from history
The solution to this problem is not to reject new terminology outright, but to approach it with a critical eye. Instead of blindly following the latest buzzwords, we should trace their roots and understand the underlying principles they represent. By recognizing that many of our "new" ideas are, in fact, old, we can focus on true innovation, building upon the solid foundation laid by the pioneers of computing. Learning from history allows us to make better design choices, avoid unnecessary hype, and ultimately create more robust and sustainable software systems.
Let us honour the legacy of those who came before us, not by blindly imitating their work, but by understanding their principles and applying them to the challenges of our time. Only then can we truly move forward, not in a cycle of reinvention, but in a continuous progression of knowledge and innovation.
References
MDN (no date) Code splitting - MDN Web Docs Glossary: Definitions of Web-related terms | MDN, developer.mozilla.org. Available at: https://developer.mozilla.org/en-US/docs/Glossary/Code_splitting (Accessed: 2 March 2025).
Naur, P. and Randell, B. (1968) SOFTWARE ENGINEERING. Available at: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF (Accessed: 2 February 2025).
NeuroLaunch editorial team (2024) Seeking Validation Psychology: Understanding the Need for External Approval, NeuroLaunch.com. Available at: https://neurolaunch.com/seeking-validation-psychology/ (Accessed: 16 March 2025).
webpack.js.org (no date) Code Splitting, webpack. Available at: https://webpack.js.org/guides/code-splitting/ (Accessed: 2 March 2025).