Closed timm closed 8 years ago
From Software Data to Software Theory: The Path Less Traveled
https://github.com/ds4se/chapters/blob/whitehead/whitehed-from-data-to-theory.md
Software engineering researchers should derive theory (and data scientist in industry should support them)
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.
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
What about:
Practitioners Need Software Theories
The core message. The example based approach.
From Data to Software Theory
https://github.com/ds4se/chapters/blob/master/whitehead/whitehead-from-data-to-theory.md
What is the chapter's clear and approachable take away message? Software Theory is Important… for everyone
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").
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?"
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.
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.
@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.
@JimWhiteheadUCSC Any updates on the revision?
@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.
@tzimmermsr
what do i tell publisher? good to go?
@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.
@tzimmermsr -- I like this change, thanks!
After review, relabel to 'reviewTwo'. After second review, relabel to 'EditorsComment'.