A PhD in software engineering, why and what to expect

This is the first episode in a series documenting a personal journey through a PhD in software engineering. The goal is not to give a definitive guide to academia, but to share observations, challenges, readings and reflections as they happen, grounded in what the literature says about doing research in software engineering.

Why a PhD in software engineering

Software engineering, as a discipline, occupies a peculiar space. It draws from computer science, mathematics, cognitive psychology, organisational theory and management. Practitioners produce systems that touch nearly every domain of modern life, yet the field continues to debate what constitutes rigorous engineering and what separates craft from science (Wohlin et al., 2012).

That tension is precisely what motivates doctoral work in the area. A PhD is, at its core, an investigation into an open question that the existing body of knowledge has not yet settled. In software engineering, open questions are abundant: How do developers understand unfamiliar code (Maalej et al., 2014)? What makes a test suite trustworthy? When does a particular architectural style become a liability rather than an asset? How much does team structure influence software quality (Nagappan et al., 2008)?

The attraction to a PhD is therefore intellectual, not merely credential-driven. The credential may open doors in certain institutions, but the real reward is the capacity to ask a precise question, design a study to investigate it, and produce an answer that can be scrutinised, replicated and built upon.

What a PhD in software engineering actually involves

The popular image of doctoral work, a solitary scholar surrounded by dusty volumes, does not map well onto software engineering research. Empirical methods dominate the field. Experiments, case studies, surveys and systematic literature reviews each serve different purposes (Wohlin et al., 2012), and choosing the right method is itself a research decision that must be justified.

Kitchenham and Charters (Kitchenham & Charters, 2007) formalised guidelines for systematic literature reviews in software engineering, a method that has become a standard entry point for many PhD projects. A systematic review forces a researcher to define inclusion and exclusion criteria before reading a single paper, reducing the risk that confirmation bias shapes what the literature appears to say.

Beyond the methodology, a PhD involves writing: proposals, progress reports, conference papers, journal submissions and ultimately the thesis. Writing is not decoration applied after the thinking; it is the mechanism by which ideas are tested. Vague claims that survive private thought rarely survive the discipline of committing them to a sentence that must be defended under examination.

Collaboration is also a constant. Most productive researchers work within a network of peers, advisors and practitioners. In software engineering, industry collaboration is particularly valuable because the phenomena being studied, code quality, developer behaviour, deployment frequency, occur in real organisations and are not easily simulated in a laboratory (Ko et al., 2015).

The state of software engineering research

Software engineering research has matured considerably since the term “software engineering” was coined at the 1968 NATO conference in Garmisch (Naur & Randell, 1969). The early decades produced foundational models (waterfall, spiral, iterative) and measurement frameworks. More recently, the community has turned its attention to empirical questions: not “what should developers do?” but “what do developers actually do, and what happens when they do it?”

Conferences such as the International Conference on Software Engineering (ICSE) and the Empirical Software Engineering and Measurement (ESEM) publish work that spans controlled experiments with students, field studies in large industrial organisations, mining of open-source repositories and mixed-methods investigations. The IEEE Transactions on Software Engineering and the ACM Transactions on Software Engineering and Methodology are among the journals that set the standard for rigour in the field.

One notable shift is the rise of repository mining. Platforms such as GitHub provide access to millions of projects, commit histories, issue trackers and pull request discussions. This abundance of data has enabled large-scale empirical studies that were simply not feasible a decade ago, though it has also introduced concerns about the representativeness of open-source data as a proxy for industrial practice (Nagappan et al., 2013).

What this series will cover

Each episode in this series will focus on a specific aspect of the doctoral experience as it unfolds. Planned topics include:

• Navigating the literature and building a reading habit that scales
• Formulating a research question and understanding its scope
• Choosing between experimental, case study and survey designs
• Writing for academic venues (conference papers, journal submissions)
• Managing the relationship between doctoral work and professional software development practice
• Reflections on test-driven development as both a subject of study and a daily practice

The series is not a tutorial and is not prescriptive. It reflects one perspective on one journey. Readers who are considering doctoral work, who are already enrolled, or who are simply curious about what academic software engineering research looks like in practice may find something useful here.

References

1. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). Experimentation in Software Engineering. Springer. https://doi.org/10.1007/978-3-642-29044-2
2. Maalej, W., Tiarks, R., Roehm, T., & Koschke, R. (2014). On the comprehension of program comprehension. ACM Transactions on Software Engineering and Methodology, 23(4), 1–37. https://doi.org/10.1145/2622669
3. Nagappan, N., Murphy, B., & Basili, V. (2008). The influence of organizational structure on software quality: an empirical case study. Proceedings of the 30th International Conference on Software Engineering (ICSE), 521–530. https://doi.org/10.1145/1368088.1368160
4. Kitchenham, B., & Charters, S. (2007). Guidelines for performing systematic literature reviews in software engineering (No. EBSE-2007-01; Issue EBSE-2007-01). Keele University and Durham University. https://www.elsevier.com/__data/promis_misc/525444systematicreviewsguide.pdf
5. Ko, A. J., LaToza, T. D., & Burnett, M. M. (2015). A practical guide to controlled experiments of software engineering tools with human participants. Empirical Software Engineering, 20(1), 110–141. https://doi.org/10.1007/s10664-013-9279-3
6. Naur, P., & Randell, B. (1969). Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 October 1968. NATO Scientific Affairs Division. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF
7. Nagappan, M., Zimmermann, T., & Bird, C. (2013). Diversity in software engineering research. Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE), 466–476. https://doi.org/10.1145/2491411.2491445