./whitehead/whitehead-from-data-to-theory.md

[timm]

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

[pruneson46]

Title of chapter

From Software Data to Software Theory: The Path Less Traveled

URL to the chapter

https://github.com/ds4se/chapters/blob/whitehead/whitehed-from-data-to-theory.md

Message?

Software engineering researchers should derive theory (and data scientist in industry should support them)

Accessible?

It is really a challenge to make this topic accessible to the generalist audience, since it mostly is a message to specialized researchers. However, I think it may be made more accessible to the generalists, and then also become motivational for the specialists. However, that involves significant change in structure and tone, as proposed below.

Size?

• The chapter is too long, and particularly, as mentioned above, it is too detailed. Examples should be used to illustrate and motivate, but that can be achieved with less detail.
• The writing style is too "academic". Shorter paragraphs, more subheadings, fewer details -- yes it hurts, but I'm afraid it's needed.
• The history-linear structure SE analogy to "Already the ancient greeks..." about the NATO conference may be relevant for researchers like me, who is interested in all kinds of historical perspectives. For a generalist, the third paragraph would be much more feasible as a starting point. "We need theory in SE to support practice..." The questions in that paragraph also work well to give the reader some ideas about what theories could be about. The historical background to bug taxonomies doesn't really make sense to me either.
• The bug classification example works fine as an example of what needs to be done (Herzig vs Tan). However, it is far too detailed. Just keep as much detail as needed to make the point for forming theories. Further, I would like to see more a research-practice collaboration agenda to address the needs for more theoretical work.
• A key point about the needs for theory is hidden in a paragraph far down in the text: "there is instability in the definitions of the most fundamental abstractions". This key issue should be brought forward to a more visible position.

Zeller et al's parody paper Failure is a four-letter word could be used as a contrasting example of what may happen if you only observe data and don't consider underlying theoretical models. http://dx.doi.org/10.1145/2020390.2020395

Gotta Mantra?

What about:

Practitioners Need Software Theories

Best Points

The core message. The example based approach.

[tzimmermsr]

Title of chapter

From Data to Software Theory

URL to the chapter

https://github.com/ds4se/chapters/blob/master/whitehead/whitehead-from-data-to-theory.md

Message?

What is the chapter's clear and approachable take away message? Software Theory is Important… for everyone

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 accessibility could be improved: the chapter is rather long (e.g., the discussion of the bug report taxonomies).

Practitioners could also be addressed earlier in the chapter (not just at the end "inspires practitioners").

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 could be shortened a little.

The bug taxonomy section didn't fit very well. It's very long and in the end it doesn't make a strong case for why theories are relevant for practitioners. The most important paragraphs are the last two ("On the one hand", "Yet, to make progress"). It's not a very strong sales pitch for why practitioners should care about theory: Some theoretical work may be needed, but from a pragmatic perspective we did just fine without any stability in the core concepts. The Hindle example is much more compelling, as it is theoretical in its nature but enables to much technology that people didn't think about before.

The bug taxonomy section could almost stand as a separate chapter "What are software bugs?"

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 title is good.

Best Points

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

The Hindle example nicely shows the value of theories (by the way, we do have a chapter on naturalness in the book). It could be emphasized by adding a section title, something along the lines "How Theory Impacts Practice"

I liked the introduction and pathways sections.

[tzimmermsr]

@JimWhiteheadUCSC Please take a look at the reviews and prepare a new version of the chapter by January 13. In particular, focus on making the chapter more accessible to a generalist audience. @pruneson46 has some great advice on accomplish this in his review, e.g., keep only as much detail as needed to make the point.

Personally I felt that most of the bug taxonomy was not needed to support the points in the chapter. I did like the historical perspective. If you want you could pull out the main (historic) parts into a separate chapter, e.g., "What are software bugs?" with the take away, it's not that easy and it highly depends on the application.

[tzimmermsr]

@JimWhiteheadUCSC Any updates on the revision?

[JimWhiteheadUCSC]

@tzimmermsr @pruneson46 Thank you very much for your insightful comments on my chapter, which I took to heart when crafting my revision.

I removed the bug taxonomy section, and will save these for inclusion in a future article (I don't think I have time to create a new chapter for this volume).

I then focused the message on "everyone needs theory".

To that end, I added another short example from my own work (power law simulation) to the existing Hindle article to strengthen the "observation to theory to practice" pathway.

I also added the Zeller "Failure is a Four Letter Word" article in the conclusion, as it provides a great way to sum up the article's main point -- thank you for the suggestion!

I also removed some of the history from the introduction, to make that go faster.

Please take a look and see what you think. I'm cautiously hopeful you'll find it much improved.

[timm]

@tzimmermsr

what do i tell publisher? good to go?

[tzimmermsr]

@JimWhiteheadUCSC I like the changes. :-) The chapter is good to go. I've made a minor fix, please check that it didn't change the meaning.

"Preferential attachment results in simulated software changes being made to larger files more commonly than smaller ones, in the software version of the rich getting richer" => "Preferential attachment results in simulated software changes being made to larger files more commonly than smaller ones --- the software version of the rich getting richer"

@timm Marked as Good to Go in the Perspective Book Status.

[JimWhiteheadUCSC]

@tzimmermsr -- I like this change, thanks!