./dyba-bergersen-sjoberg/WhyYouShouldUseTheory.md

[timm]

After review, relabel to 'reviewTwo'. After second review, relabel to 'EditorsComment'.

[dspinellis]

Title of chapter

Why Theory Matters

URL to the chapter

https://github.com/ds4se/chapters/blob/master/dyba-bergersen-sjoberg/WhyYouShouldUseTheory.md

Message?

What is the chapter's clear and approachable take away message?

Software engineering theories are important and approachable

Longer version: Software engineering theories allows us to predict, explain, understand, and synthesize phenomena. They can be described in terms of terms of constructs , propositions, explanations, and scope.

Accessible?

Is the chapters written for a generalist audience (no excessive use of technical terminology) with a minimum of diagrams and references? How can it be made more accessible to generalist?

The authors do a good job in making a case on a difficult topic. I admit that as an empiricist I'm not particularly versed on the subject and have little patience with idle theorizing. The authors managed to convince me regarding the importance and the accessibility of theory building in software engineering.

Size?

Is the chapter the right length? Should anything missing be added? Can anything superfluous be removed (e.g. by deleting some section that does not work so well or by using less jargon, less formulae, lees diagrams, less references).? What are the aspects of the chapter that authors SHOULD change?

The chapter is a concise, convincing, and interesting introduction to theory in software engineering.

The constructs used in the paper need to be clarified. Specifically, a technology's difficulty is not directly related to the performance that can be achieved with it. I offer as counterexamples two difficult but low performing technologies: the unicycle, and the Brainf*ck programming language. Both are quite difficult but low performing technologies.

I propose that the authors rework their constructs, propositions, and the cart to take into account task performance (how well the task is being accomplished) and ideal technology performance (how well a specific technology performs at the hands of an expert). What is currently termed difficulty should instead be the ratio of ideal performance over difficulty, which a measure similar to efficiency.

Gotta Mantra?

We encouraged (but did not require) the chapter title to be a mantra or something cute/catchy, i.e., some slogan reflecting best practice for data science for SE? If you have suggestion for a better title, please put them here.

The Chapter begins with “Data without theory is blind, but theory without data is mere intellectual play.” I find it succinct and catchy. However, I have difficulty picturing data without theory as blind, because data can't "see". Perhaps writing "data without theory is mute" might be more suitable paraphrasing.

Best Points

What are the best points of the chapter that the authors should NOT change?

The introduction and Constructs sections allow a reader with minimal background knowledge to quickly grasp (in theory) the importance of theory and what it takes to build one.

Suggestions for small corrections

• [ ] You write " Theories help reduce the complexity of the world". I think that theories help reduce the apparent complexity of the world. (I admit that this point is rather philosophical, but why allow it to be raised, when you can easily fix the issue.)
• [ ] You end your chapter writing "But one has to start theorizing first." I understand the point, but there are also alternative approaches that many think as equally valid. Would you perhaps consider a small mod toward the empiricist camp?

[timm]

Review from David Budgen

Title: Why Theory Matters

URL:

https://github.com/ds4se/chapters/blob/master/dyba-bergersen-sjoberg/WhyYouShouldUseTheory.md

Message

Data collection for research and analysis needs to be undertaken with and for a purpose, and this purpose should be driven by a theoretical model.

Accessible

I’m completely on board with the message of this chapter, and i think the issues are presented well, but I’m less sure that the terminology is quite right. I think that for many people, the term ‘theory’ = ‘mathematical formalism’ (especially in computing), which is often seen as rather sterile and detached from reality. Whereas this chapter is really about ‘theoretical models’ that can take many forms, including cognitive models in particular. However, that doesn’t come over in either the title or the introduction, although it permeates the rest of the chapter. My real problem is that I can’t really suggest a better term to use, other than perhaps ‘theoretical models’.

My only other point is whether “How to build theory” quite gets the incremental nature of this process across. Theories are a bit like designs, they don’t spring fully-formed from first attempts (well, not usually, especially for we mortals).

Size

Good, I thought it got the message over well and quite concisely.

Gotta Mantra?

I thought the title catchy, although as above, I’m a bit concerned that some people will possible not read further because of it.

Best points

The use of examples does give this real authority.

I have suggested a few phrases that might be modified, but feel free to ignore my points.

First para: I’d suggest that rather than “make meaning from”, you use “obtain meaning from”.

How to build, para 1: “accept critique for the initially proposed theories” is a bit hard to scan, although quite correct. I’d suggest ‘seek’ rather than ‘accept’ (or “seek and accept”) and then drop ‘initially’ which isn’t really needed if you have ‘proposed’. I also wonder whether it should be ‘theory’, since one wouldn’t usually be doing this for multiple theories, and the previous sentence used a singular form.

How to build, para 2: rather than “perhaps the reversal effect” might be “could it be that the reverse effect” to make it more of a question.

[lauriew]

In the revision, please come to a conclusion on "[[possible link to the chapter “Correlation is not Causation” by Dybå et al.]]"

In "how to use theory" you start out with "participants" then "consultants" then "juniors" then "developers" -- please clarify and use more consistent terminology.

Put the references in the text to the references in the list at the bottom of the chapter.

In how to build a theory, I'd make the general definition of the constructs of the theory more prominent than "a theory in terms of constructs (the basic elements of the theory), propositions (the interactions among the constructs), explanations (the reasons for the claimed interactions) and scope (the circumstances under which the theory is valid)."