First things first: If software engineering is the solution, then what is the problem?

Software engineering (SE) undergoes an ontological crisis and it lacks of a theory. Why? Among other reasons, because always it succumbed to the pragmatism demanded by the commercial and political interests and abandoned any intention to become a science instead of a professional discipline. For beginning a discussion for define a theory of software, first, is required to know what software is.

💡 Research Summary

The paper argues that software engineering (SE) is currently suffering from an ontological crisis because it has failed to develop a coherent scientific theory and has instead been driven by pragmatic concerns rooted in commercial and political interests. The author contends that SE has long positioned itself as a professional discipline focused on delivering immediate, market‑driven solutions, while neglecting the deeper theoretical foundations that would allow it to be recognized as a science. This pragmatic orientation, reinforced by industry pressure for rapid product releases and cost reductions, has led to curricula and research that prioritize project management, agile methods, and quality assurance over the systematic study of software itself.

To address this crisis, the paper insists that the first step is to answer the seemingly simple question: “What is software?” The author proposes a multi‑layered definition that treats software not merely as code or executable artifacts but as (1) a collection of explicit algorithms and data structures, (2) an abstract mechanism mediating interactions among systems, users, and environments, and (3) a socio‑economic product shaped by legal, ethical, and market forces. By adopting this comprehensive view, SE can shift its focus from merely managing development processes to investigating the intrinsic properties of software as an object of scientific inquiry.

Building on this definition, the paper outlines three major theoretical tasks for SE. First, it calls for an integration of formal methods (type theory, formal verification, mathematical logic) with practical engineering concerns, creating a unified framework that links design, verification, and deployment under a common theoretical umbrella. Second, it advocates for a lifecycle‑wide “problem‑solution‑value” model that formally captures the flow from requirements elicitation through maintenance, ensuring that each phase is grounded in a consistent theory of software behavior and evolution. Third, it emphasizes the need for metrics and policy models that quantify software’s impact on economic, regulatory, and ethical domains, thereby providing decision‑makers with scientifically justified criteria for technology selection and governance.

The paper critiques existing SE research for its narrow emphasis on process improvement and tooling, noting the absence of meta‑theoretical work that examines software’s nature. It proposes future research directions, including mixed‑method approaches that combine formal and informal analyses, socio‑technical system theories that model human‑software interaction, and sustainable software ecosystem studies that incorporate economic and policy modeling.

In conclusion, the author asserts that SE must transcend its role as a problem‑solving craft and evolve into a discipline that treats software as a scientific object. This transformation requires a concerted effort among academia, industry, and policymakers to develop shared research platforms, standardized metadata, and collaborative governance structures. Only by establishing a robust theoretical foundation can SE regain its academic identity, foster long‑term innovation, and support the creation of sustainable, trustworthy software systems.