Eighty years ago, there wasn’t a such thing as a “software engineer.” Computers were widely less popular than they are today, and it would be crazy to talk about earning a living by developing “software” for “computers.” However, today, software engineers are one of the most in-demand jobs in the United States. This is because of the explosion of technology in recent years, but there is also something deeper going on: rationalization.
Rationalization, or McDonaldization, is defined as a phenomenon that occurs when society, or an aspect of a society, adapts its processes to behave more like a fast-food chain. It occurs across four dimensions: predictability: having a consistent effect, calculability: being able to measure effectiveness, efficiency: more effectiveness for less cost, and control: non-human technology to control humans or processes. Somewhat counterintuitively, through rationalization, software engineers have become more like writers and less like calculators. They collaborate with increasingly more professions, have to worry less about syntax, technical details, and exact implementations, and instead can worry about how the code reads to other developers and how maintainable it is.
However, according to Ritzer, all rationalization comes with its own irrationalities, including the rationalization that comes with software engineering. According to Ritzer, an irrationality is when a rational system produces unreasonable, inhuman results: sacrificing quality or sacrificing the humanity of those that work within it (Ritzer 2020). The rationalization of software engineering has produced many irrationalities, although they are unique in nature.
Origins of Software Engineering
Software engineering has come a long way since the beginning of modern computing. From having no concept of a computer, to computers the size of the room, to modern computers more powerful than those large computers in the pockets of the general public, computing, and in tandem software engineering, has come a long way.
Origins of Modern Computing
Despite the stereotype of the straight white male sitting at a computer writing code, computing has quite diverse roots. Ada Lovelace is known as the first computer programmer, recognizing that the computer had applications beyond simple calculation back in 1841.
The first general-purpose computer, known as the ENIAC, was built based on his model. Interestingly, the ENIAC’s programmers were women, due to a shortage of male engineers in World War II and also because women were believed to be better suited to programming at that time.
Computing had not been hit by the wave of rationalization just yet, as it was still in its ideation stages. Few people dealt with computers and the first general purpose computer had not been invented. Programmers in the early days were largely scientists conducting research and individual people or small teams employed by large companies.
The Beginning of Software Engineering
The term “software engineering” was coined by Margaret Hamilton in 1969 to add legitimacy to the practice. She worked on software that guided Apollo to land on the moon. In the early days of software engineering, there was no formal training for the craft, and it was taken much less seriously than other parts of the process for landing the craft on the moon. However, in order to be successful, the software team had to do what software engineers today do: make their software robust to errors, known and unknown. Software on the Apollo mission was just as critical as other parts of the craft: if the software went down anywhere, the entire craft would crash. Since then, the term “software engineering” has continued to be used to emphasize the legitimacy of the profession, a fight that continues to this day. It can also be argued that the coining of the term “software engineering” as well as other efforts to promote its importance started the surge of formal training and research in the field. Today, a Google Scholar search for “Software Engineering” sparks 6,540,000 results of articles, books, and more on how to further the profession and build better software.
Rationalization Over the Years
Over the years, software engineers have heavily rationalized the tools they use, optimizing them for the four pillars of efficiency, calculability, predictability, and control. While there are countless innovations that have been made in the field, a few stand out as clear examples of rationalization of the work of software engineers.
Version Control Software
One example of how software engineering has been rationalized is through the increased use of version control. Version control allows users to track changes, undo changes, work on code at the same time. When code is so easy to break, version control is essential for any software project. Version control was invented about 10 years after the birth of software development starting with the Source Code Control System by Bell Labs. Since then, distributed version control systems were invented that allowed users to work on their own local copies of the code more easily, starting with BitKeeper. The free version of this software prompted Linux developers to create Git, an open-source solution with all the features of BitKeeper and more in 2005. This, along with the creation and popularity of GitHub in 2008 and GitLab in 2011, has created essentially a single workflow for developers of all projects and sizes. Additionally, using GitHub and GitLab allows for users to easily create a “pull request,” giving developers even more control of what goes into the final version of their code. Pull requests do not allow changes to be made to a branch or a repository until a user with permissions reviews and accepts them, automatically providing quality control of every line of code (Ruparelia 2010).
Integrated Development Environments
Before the 1980s, programmers juggled separate tools: compilers, terminals, and text editors. Integrated Development Environments (IDEs) emerged, combining these into one user-friendly platform. Now used by 73% of developers, IDEs offer features like autocomplete, syntax highlighting, and refactoring, significantly streamlining the development process (Valishery 2024).
This exemplifies rationalization in software engineering. IDEs not only boost efficiency, but also predictability and calculability. They reduce errors in basic tasks, making projects more consistent. Additionally, IDEs automatically track various metrics, like lines of code written or function usage, enhancing calculability.
Open Source Software
The rise of open-source software (OSS), where code is freely available and often community-maintained (think GitHub), has significantly rationalized development tools. OSS's popularity is undeniable – Git (used by over 93% of developers) is open-source, and extensions for popular IDEs like Visual Studio Code are often community-developed. Even core technologies like Linux (web servers), Blender (3D modeling), Python (data science), and partially even Android, rely on open-source principles. These tools, built by passionate developers for developers, exemplify the unique situation in software engineering: engineers themselves are driving their own rationalization through open-source collaboration.
Pictured: Lux, the Linux Mascot
Effect of Rationalization of Engineering Tools
Apart from making software engineers more efficient, the overall effect of the rationalization of engineering tools is that developers can focus less on the exact code semantics and more on the ideas behind the code and its effect on other developers or maintainers. Put another way, software engineering has become less technical, and more social.
Programs are meant to be read by humans and only incidentally for computers to execute. – Donald Knuth.
This is only possible through the forces of rationalization of engineering tools and becomes truer as they become further rationalized. If a programmer were to write a program with absolutely no syntax highlighting, autocomplete, or compilers hinting where the error is at, the human readability of code simply has to take the back seat to getting the computer to understand a simple operation. The vast majority of the developer’s focus would be on getting the computer to understand a program, rather than the people that would be reading the code.
This trend of software engineering becoming more social coincides with, and perhaps is exacerbated by, the increase of diversity of software engineering. Although software engineering and computing was founded by diverse voices, shortly after its founding, it came to be dominated by white males. However, it has since been becoming more diverse, with new voices being more diverse than ever, exhibiting a steady growth in female representation as well as ethnically diverse representation.
Irrationalities in the Rationalization of Engineering Tools
Software engineering strives for progress, often through simplification and abstraction. While high-level languages and design patterns make development faster, they can introduce unintended consequences. Wirth's Law, for example, describes software slowing despite hardware advances. This paradox arises from prioritizing short-term development ease over long-term performance.
Traditional developer education emphasizes sustainable design practices, but these may not hold true forever. Focusing solely on such practices could leave developers unprepared for a future where hardware limitations become more prominent. This highlights the need to move beyond a purely rationalized approach to software development, considering both immediate benefits and potential long-term drawbacks (Xu et. al 2010).
Resistance To Rationalization of Software Engineers
In contrast to rationalizing the tools they use, attempts at rationalization by upper management has largely not been effective or beneficial. In this way, software engineers become primarily drivers of rationalization rather than objects of it. While software engineers are willing and excited to gain control over the code they use, attempts from managers to further control engineers’ work has backfired. While engineers are happy to increase their own efficiency through rationalization, attempts to increase developer’s efficiency directly has largely backfired. The same is true for all four dimensions.
Work of a Software Engineer Hard to Rationalize
There are inherent properties of a software engineer’s job and data that suggests that attempts to rationalize the process that they work under will hinder their effectiveness across all four dimensions.
• Efficiency: Software engineering is creative and complex. Unlike repetitive tasks, efficiency gains are hard to achieve externally. Software engineers are already optimizing their workflows, and managers may not have the deep understanding required to make effective changes.
• Predictability: Predicting software development timelines is notoriously difficult. Game delays, for instance, highlight the inherent challenges (Robson 2023).
• Calculability: Metrics like lines of code written don't accurately reflect an engineer's effectiveness. Removing bad code is essential, and mature projects may require fewer code changes. There's no universally agreed-upon metric to solve this (Voas and Kuhn 2017).
• Control: Software engineer autonomy and satisfaction are linked to their effectiveness. Control measures often backfire. Agile development, for example, suffers when implemented with a controlling mindset (França 2020).
Agile Development: a failed attempt at rationalization?
Agile development, a widely adopted approach used by over 70% of developers, promises increased control for managers. However, it can lead to unintended consequences for developers. While some report improved visibility (59%) (17th State of Agile), a concerning 16% drop in satisfaction occurred between 2022 and 2023 reports. This dissatisfaction persists despite Agile's continued use, perhaps due to its perceived benefits.
The issue lies in the potential for metrics-focused Agile to turn developers into "feature machines," sacrificing creativity for efficiency: telltale marks of attempts at rationalization. Furthermore, these practices don't guarantee better software quality. Only 25% of satisfied users in the 2023 State of Agile report credited the methodology with improvement, raising questions about its overall effectiveness. Even development times can suffer: 37% of dissatisfied users blamed Agile for causing delays (17th State of Agile). These findings suggest a need to re-evaluate how Agile is implemented to balance control with developer well-being and project success.
Generative AI and an Uncertain Future for Software Engineering
In recent years, probably the most talked about technology is generative AI. Unlike other technologies that have come before, programs like ChatGPT allow users to simply describe code they want to write, and then it will be given. Although the programs are not perfect, they are good enough to raise the question: has there come and will there come a time where software engineers will rationalize themselves away? There are many arguments for and against this being the case.
Arguments for Generative AI replacing Software Engineering
Some argue that generative AI spells the end of software engineering as we know it. Historically, no program has reliably written and debugged its own code. However, generative AI shows promise. We can imagine a future where AI utilizes these models to not only write code, but also run and fix errors autonomously.
Another viewpoint suggests a future with far fewer software engineers, but with significantly different roles. Companies might transition from employing large development teams to a single engineer or designer who acts as an intermediary, providing specifications to the AI for self-construction. Alternatively, small teams might guide the AI through development, focusing on debugging and ensuring smooth operation.
The rapid evolution of Large Language Models (LLMs) fuels these arguments. Similar to Sora AI's dramatic improvement in video generation within a year, LLMs could experience exponential growth. This rapid advancement has the potential to fundamentally reshape the software development landscape, making the future of software engineering undeniably uncertain.
Arguments Against Generative AI Replacing Software Engineering
Despite the concerns, several factors suggest a less dramatic future for software engineering.
First, current evidence points towards a more collaborative future. Studies like the one analyzing GitHub activity during Italy's ChatGPT ban show modest productivity gains, particularly for experienced developers. Generative AI seems poised to assist with routine tasks and bug fixing, not replace engineers entirely (Kreitmeir et al. 2024).
Second, focusing solely on software engineering ignores the broader job market. Professions closely tied to AI development might overestimate its impact on software engineers specifically. Additionally, claims of widespread replacement raise social concerns. Software engineering has been a "safe" career path for many, and downplaying its future could discourage potential entrants. While web developers face a calculated risk of automation around 39%, the social and creative aspects of software engineering make it less vulnerable (Will web developers... n.d.).
Finally, technical limitations could hinder the rapid advancement of AI. Large language models are often "black boxes," making it difficult to directly improve them. Additionally, existing methods of improvement have diminishing returns and escalating costs. Legal issues surrounding training data privacy and copyright also pose challenges.
The Likely Scenario
The future of software engineering with generative AI remains uncertain. Like past advancements (syntax highlighting, compiler errors), generative AI seems likely to extend the trend towards higher-level thinking. Imagine software engineers making decisions in natural language, with AI handling the code details. While obstacles exist, it's early days for this technology. Predicting the future definitively is impossible.
Conclusion
Despite typically being managed by other people and being a very popular occupation, software engineers occupy a unique space in the workforce being drivers of rationalization while heavily resisting being rationalized themselves. Tools such as open-source software made by other passionate developers and version control empower software engineers to be drivers of their own transformations. While generative AI could be a turning point in this trend, the future is anything but certain.
References
Digital.Ai. (2024, March 7). 17th State of Agile Report: Analyst Reports. https://digital.ai/resource-center/analyst-reports/state-of-agile-report/
Booch, G. (2018). The history of software engineering. IEEE Software, 35(5). https://ieeecs-media.computer.org/media/marketing/cedge_newsletter/ce9boo.pdf
Cico, O., Jaccheri, L., Nguyen-Duc, A., & Zhang, H. (2021). Exploring the intersection between software industry and software engineering education - A systematic mapping of software engineering trends. Journal of Systems and Software, 172, 110736. https://doi.org/10.1016/j.jss.2020.110736
Erdogmus, H., Medvidović, N., & Paulisch, F. (2018). 50 years of software engineering. IEEE Software, 35(5), 20-24. https://doi.org/10.1109/MS.2018.3571240
França, C., da Silva, F. Q. B., & Sharp, H. (2020). Motivation and satisfaction of software engineers. IEEE Transactions on Software Engineering, 46(2), 118-140. https://doi.org/10.1109/TSE.2018.2842201
Hoda, R., Salleh, N., & Grundy, J. (2018). The rise and evolution of agile software development. IEEE Software, 35(5), 58-63. https://doi.org/10.1109/MS.2018.290111318
Hou, D., & Wang, Y. (2009). An empirical analysis of the evolution of user-visible features in an integrated development environment. In Proceedings of the 2009 Conference of the Center for Advanced Studies on Collaborative Research (CASCON '09) (pp. 122–135). IBM Corp. https://doi.org/10.1145/1723028.1723044
Kreitmeir, D., & Raschky, P. (2024). The heterogeneous productivity effects of generative AI. SoDaLABS, Working Paper Series.
Lorey, T., Ralph, P., & Felderer, M. (2022). Social science theories in software engineering research. In Proceedings of the 44th International Conference on Software Engineering (pp. 1994–2005). Association for Computing Machinery. https://doi.org/10.1145/3510003.3510076
Martinez, M. (2023, July 18). 50 years of software. IEEE Computer Society. https://www.computer.org/publications/tech-news/trends/50-years-of-software
Ruparelia, N. B. (2010). The history of version control. ACM SIGSOFT Software Engineering Notes, January 1. https://dl.acm.org/doi/pdf/10.1145/1668862.1668876
Ritzer, G. (1996). The McDonaldization of society: An investigation into the changing character of contemporary social life. Pine Forge Press.
Robson, K. (2023, February 2). Why are so many video games delayed and cancelled? Verdict. https://www.verdict.co.uk/why-are-so-many-video-games-delayed-and-cancelled/
Vailshery, L. S. (2024, February 12). Tools used by software developers worldwide 2022. Statista. https://www.statista.com/statistics/869106/worldwide-software-developer-survey-tools-in-use/
Voas, J., & Kuhn, R. (2017). What happened to software metrics? Computer (Long Beach Calif), 50(5), 88-98. https://doi.org/10.1109/MC.2017.144
Xu, G., Mitchell, N., Arnold, M., Rountev, A., & Sevitsky, G. (2010). Software bloat analysis: Finding, removing, and preventing performance problems in modern large-scale object-oriented applications. In Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research (pp. 421–426). Association for Computing Machinery. https://doi.org/10.1145/1882362.1882448
Will web developers be replaced by AI & robots? (n.d.). Will Web Developers be replaced by AI & Robots? https://willrobotstakemyjob.com