The Dangerous Dogmas of Software Engineering

To legitimize itself as a scientific discipline, the software engineering academic community must let go of its non-empirical dogmas. A dogma is belief held regardless of evidence. This paper analyzes the nature and detrimental effects of four software engineering dogmas - 1) the belief that software has “requirements”; 2) the division of software engineering tasks into analysis, design, coding and testing; 3) the belief that software engineering is predominantly concerned with designing “software” systems; 4) the belief that software engineering follows methods effectively. Deconstructing these dogmas reveals that they each oversimplify and over-rationalize aspects of software engineering practice, which obscures underlying phenomena and misleads researchers and practitioners. Evidenced-based practice is analyzed as a means to expose and repudiate non-empirical dogmas. This analysis results in several novel recommendations for overcoming the practical challenges of evidence-based practice.

💡 Research Summary

The paper argues that for software engineering to achieve genuine scientific legitimacy, it must abandon four entrenched, non‑empirical dogmas that currently dominate both research and practice. It begins by defining a “dogma” as a belief held irrespective of evidence and then systematically deconstructs each of the four target dogmas.

1. The belief that software has well‑defined requirements – The authors point out that extensive field studies show requirements are often vague, evolving, and co‑constructed through ongoing stakeholder interaction. Treating requirements as fixed specifications leads to inflated change‑management costs and hampers collaboration.

2. The division of software engineering work into analysis, design, coding, and testing – While historically rooted in waterfall models, the paper cites abundant empirical evidence from agile, Scrum, and DevOps environments that work is inherently iterative, concurrent, and feedback‑driven. Rigid phase separation stifles team autonomy and reduces the effectiveness of rapid feedback loops.

3. The belief that software engineering is primarily concerned with designing “software” systems – Drawing on systems‑thinking and complexity theory, the authors argue that software is only one component of a broader socio‑technical system that includes hardware, networks, organizational culture, and human factors. Ignoring these interactions leads to integration failures and higher maintenance costs.

4. The belief that software engineering methods are applied effectively – Survey data reveal low adoption rates for many prescribed methods, and case studies demonstrate that success depends heavily on organizational culture, practitioner skill, and project context. The dogma masks the reality that method effectiveness is highly situational.

The paper then introduces Evidence‑Based Practice (EBP) as a remedy. Borrowed from medicine, EBP integrates systematic literature reviews, empirical data, and expert judgment to guide decision‑making. Applied to software engineering, it would require the systematic collection of empirical studies for each dogma, meta‑analysis to extract generalizable knowledge, and continuous measurement of method effectiveness in real projects. The authors acknowledge challenges such as data accessibility, research cost, and cultural resistance, and propose concrete strategies to overcome them, including shared repositories, collaborative industry‑academia research programs, and incentives for publishing negative results.

Finally, the authors present actionable recommendations: (1) reconceptualize requirements as an ongoing discovery process; (2) replace rigid phase models with feedback‑centric iterative cycles; (3) adopt holistic system‑design frameworks that account for socio‑technical interactions; (4) select and tailor methods flexibly, measuring their impact continuously; and (5) build a community‑wide evidence base through joint data‑sharing initiatives and regular meta‑analyses. By critically examining and repudiating these dogmas through evidence‑based practice, the paper envisions a more empirically grounded, adaptable, and scientifically credible discipline of software engineering.