Grumbling about feedback (unnecessary)

Third day in Finland. Yesterday I wrote, wrote, wrote and in the evening helped my webman to setup a feedback formula. The writing is for an article, which got a lot of review feedback and I have to see if I can mold an article on Tick-the-Code to fit into a scholarly journal. I have some ideas how to do it, but some of the comments from the reviewers still seem absurd. One of the comments made me think that the job of a quality assurance (QA) person is to keep himself employed, not improve quality. It was the strangest comment. If I suggest a way to improve product quality without the need of QA, how is that a bad idea, generally?

Some of the comments seemed to be misunderstood on purpose and I have a hard time accepting them. For example, my sentence "The value of inspections is well-known at least in the academic circles" got a reviewer comment "is the value of inspections only known in academic circles?" and I have to double-check that that's what it says.

Also I noticed a difference in style when writing to a scholarly journal in comparison to writing to a professional commercial magazine. The use of strong adjectives and nouns needs to be avoided in the more scientific text. At least that is what some of the reviewers are urging me not to use. Words like "frantic", "hostile", "chaos", "devastating", "catastrophically", "precious", "sacrifice", "courage" and "brave" are apparently not acceptable or appropriate for scientific text. I need to modify my style of writing quite a bit, as I tend to use strong words to imply my meaning. I take it as good exercise. Maybe the use of strong words comes from the human, so called soft approach to matters, which tends to be hard for hard-science types. Anything linked with psychology or behavior seems out of bounds when you're trying to write scientific text. However, many of the benefits of Tick-the-Code come from the soft side of the matter. The way people get to communicate more effectively, the way the negative feedback is packaged as improvement suggestions and generally the voluntary approach to the whole checking are all more or less behavior-dependent, soft issues.

One criticism, which I accept, is that Tick-the-Code is nothing new and the level I wrote the first article draft was too low. The original was targeted to the software developer, but the readers actually are more advanced quality practitioners. My idea is now to leave out most of the details of the method, explain the case study and what it means and make it clear that Tick-the-Code is an excellent way to harness the powers of the developer staff for quality. I want to say that testing is not enough, I might actually bring out the idea of spotting higher than normal likelihoods of error, which Tick-the-Code is excellent in finding. I need to say that Tick is different from all the known inspection methods, it is unique, but I'm not sure I like the name "baby-inspection" that one reviewer gave it.

---

Suomeksi: Korjailin eilen artikkeliehdotustani, ja illalla rakenneltiin palautelomaketta weppimiehen kanssa. Tänään oli pari tapaamista ja huomenna pääsee tositoimiin. Kaksi ryhmää odottaa.

Älkää välittäkö yläosan narinasta. Palaute on aina hyödyllistä.