A first step in a one-person research project in a domain new to a researcher (Ph.D. student) is to read-up on related work. This can be daunting, as sometimes it feels like everything has been done already, and there is nothing new to write a dissertation about. Fear not! With enough digging, the opportunities will present itself.
In software engineering research, the value of past engineering work can be confusing. What does it mean that there is an open source project in which someone implemented something similar to your idea? And even wrote a blog post or report about it? The short answer: This is a golden opportunity for fabulous research and not a threat to your idea.
The key output of research is a theory or something supporting the building or validation of a theory. A theory, in turn, is knowlege, for example in the form of a model, that lets us predict the future or create reliable output in some form. Scientists usually publish theories for other scientists to review, in journals.
But what about the practitioners that we are creating the theories for in the first place?
In this video I present a way of codifying (presenting) theories as practical pattern handbooks so that practitioners can use these handbooks and apply your theory. This way, we connect science to practice and hopefully help make the world a better place. It also helps to get industry engaged in your work.
An associated (preprint) technical report, soon a journal paper, is available with more information. The slides for the video above are also available.
My usual reviewing fee for Elsevier journals is one full year of free access to your digital library for my university.
However, Elsevier has locked out German universities from accessing research on their websites, including our own. So in addition to my usual fee I must also ask that you return to the negotiating table and find a way that we can access our research again.
The short answer: This question is click-bait and was written to incite reflexes rather than reflection. The long answer: The question is a red herring, because a researcher arguing that research shouldn’t have to have a purpose is actually complaining about society not seeing the value of their research as they do.
Informatics (worse: Computing science; even worse: Computer science) is the discipline of automated data processing (where automation is both human independent and dependent, and data in context becomes information). The non-IT industry has learned the hard way over the last few decades that informatics is part of their core business, not just some support function. Financial institutions, automotive suppliers, advertising agencies and so forth are all recognizing that informatics is a key business aspect for them.
Effective writing is important, or you won’t be understood and achieve your goal. An example is to get the ordering of nouns (or adjectives) in enumerations right. Let’s pick an example: In software engineering, a software feature’s implementation should be correct, complete, and testable. So a project goal could be “to ensure correctness, completeness, and testability of feature implementations.”
Over on Facebook of all places, I took part in a short discussion on how, as a researcher, to have an impact on practice. It is not a convenient answer, but in my opinion, if you want to have an impact, you should go into practice yourself. You can also send your students, but this creates a generational lag of research-to-practice transfer that can span decades.
One of the suggestions of how to have an impact was to perform action research. The idea is that you are creating change in an organization where you are performing said action research. However, action research is a research method whose purpose it is to help you build out and evaluate a theory. Unless you are into critical theory, action research does not have, as a primary goal, to change industry. It is just a theory building method.
Many computer science degree programs do a lousy job at teaching science. A high school student, entering university, often has a good idea what science is about, based on their physics and chemistry classes. At least, it involves controlled experiments. At university, this is rarely picked up, and computer science students are given the idea that programming something novel constitutes science. With that idea, they are often bewildered when I teach them rigorous research methods, in particular if those originated in the social sciences (like qualitative interviews or hypothesis-testing surveys).
Pay-walled publications are just that: Publications that nobody reads unless someone pays the publisher’s fee. I have no problem with that, because I don’t read pay-walled work and don’t consider it published research and prior art that I should care about.
The real problem starts with researchers and editors who expect me to find, read, and consider pay-walled work as prior art. That’s an unacceptable proposition to me and an unfair one to the world.
In software engineering, the structure of research theses, most notably dissertations, is straightforward: (1) Formulate a research question, choose a method, build a theory, then (2) generate at least one interesting hypothesis, choose a method, and test the hypothesis as part of the theory’s attempted validation. A dissertation can do both parts 1 and 2 or just one of them, relying on or leaving stuff to others. The benefit of this structure is that it will be easily recognized by other researchers and make it eas(ier) to write great papers.