barik
commented
8 years ago Title of chapter
Inductive Software Engineering: What we do IS Different
URL to the chapter
https://github.com/ds4se/chapters/blob/master/menzies/inductiveManifesto.md
Message?
The article provides seven principles of inductive software engineering, which focuses on delivering data-mining based software applications to users.
Accessible?
I found the language to be accessible. There's some nice conversational-style use of language ("That whole inductive manifesto is a little long"), which helps with the flow of the article --- and it's not overdone.
In the first section, "Different and Important", I wasn't super clear on what it is that inductive software engineering is different from. Is the contrast between industrial practitioners (who focus on users) and academics (who focused on algorithms) the difference? Or is it more in terms of SE versus other disciplines? If so, how is it different? The introduction starts with how "Induction-for-SE is different to induction in other fields," but at this point I don't feel like I even know what induction means, let alone that it is something that is done in other fields. Some more hand-holding here would be appreciated, please -- otherwise, when I hear the word induction my first thought is to scary discrete math subjects!
The last paragraph of "Different and Important" might offer a small bit of sign-posting to let me know that I'm about to see several principles ("so here we offer a summary of seven key principles." or something to that effect). Actually, I was left wondering what it was that was being summarized -- did the original manifesto have seven principles also, and you're just condensing them, or is this just taking some subset of the original manifesto?
The breakdown in terms of principles was nice, and in general, easy to digest. There's some inconsistency in that some of the principles are verb-style principles ("Plan for scale") whereas others are not ("Smart Learning").
I didn't quite get the transition from Principle #5 ("Smart Learning") to Principle #6 ("Live with the data you have"). The paragraph starts with "One way to do smart learning, that was not listed above [...]," which seems awkward. Probably fixed just by removing this whole sentence and starting it with "In our experience, we can only ...".
Size?
The principles, for the most part, were the right length. I felt that Principle #2 was disproportionately long compared to the other principles. My feeling is that the CRANE story could be condensed into something that is a simple paragraph. The whole "the way it started was not the way it ended" sections I thought were a little too detailed for this type of article. Also the conclusion of this principle was not what I expected -- it seemed like the take-away was that you need to have larger teams, which seemed at odds to some extent with the initial message of automation or minimizing point-and-click analysis?
Principle #5 has some items that I don't think are at the appropriate level of abstraction; the last two bullet points about the mean are so low-level that it doesn't seem to fit with the higher-level take-away. You might consider removing them.
Gotta Mantra?
The mantra as stated is that the Inductive Software Engineering is different. I think if that's true each principle will want to tie back to this paradigm difference. That is, for each principle, what is the difference that this principle has in IS that is different from other disciplines. That would let the "Different and Important" narrative flow throughout the article.
One idea is that the title should explicitly point out the principles: "Seven Principles of Inductive Software Engineering: What we do IS Different."
Best Points
I like the "thou shalt not click" sub-principle. I would definitely keep that. The use of bullet-points was good, with some exceptions indicated earlier. In general, I would also keep the seven principles break-down: it makes it easier to digest the article in small chunks this way.
Minor nitpicks:
- "fund their use" -> "find their use"?
- In some places, the article "engineering" when I think it's meant to be "engineer".
- Principle #1: Bullet-points need a quick grammar check. "Do the users indicates" -> "Do the users indicate" and so on.
- Principle #2: Semi-colon between bullets?
- Principle #7: Ends with period in heading.
tzimmermsr
timm
After review, relabel to 'reviewTwo'. After second review, relabel to 'EditorsComment'.