Comments for It Will Never Work in Theory

Comment on The social dynamics of pair programming by Jorge Aranda

Jorge Aranda — Thu, 09 May 2013 15:17:07 +0000

Thanks for chipping in, Sallyann. I’m very curious about distributed pair programming too—and skeptical on its effectiveness.

Comment on The social dynamics of pair programming by Sallyann freudenberg

Sallyann freudenberg — Thu, 09 May 2013 15:01:20 +0000

I was previously Sallyann Bryant. My studies were across 4 different companies, some of which I studied several teams. In all I analysed 15,000 sentences of pair programmer dialogue. They were all collocated. I would be fascinated to see how the roles are similar and different in distributed pairs !

Comment on Supporting Professional Spreadsheet Users by Generating Leveled Dataflow Diagrams by From spreadsheets to dataflow diagrams | Modeling Languages

From spreadsheets to dataflow diagrams | Modeling Languages — Tue, 07 May 2013 04:50:17 +0000

[...] It will never work in practice, I discover the work (and of Felienne Hermans, Martin Pinzger and Arie van Deursen on [...]

Comment on Why We Need Evidence by Geert Bollen

Geert Bollen — Fri, 22 Mar 2013 12:47:15 +0000

I come to this conversation late, but there is a class of coarse-grained research questions for which I would consider evidence extremely useful to software practitioners. It is this: “Does Xyz have an effect in the first place?”

Adoption or even long-term survival in the market is an unreliable proxy for this question given human psychology.

But with reliable (negative) evidence, I could at a stroke ignore all advocates of Xyz and their claims in my quest to discover practices that might be helpful in my context. Would that be useful? You bet it would!

It might even stop the software field chasing its tail quite as much as it does today. Only trouble is, generating negative results isn’t a terribly popular occupation.

Comment on Experimental Assessment of Software Metrics Using Automated Refactoring by Graham

Graham — Wed, 27 Feb 2013 10:01:34 +0000

This reminds me of another paper, “Legacy Software Restructuring: Analyzing a Concrete Case” (http://arxiv.org/abs/1210.7138v1, also presented at CSMR 2011). They found that over a few major restructurings of the Eclipse platform, coupling did not always decrease, cohesion did not always increase, and the number of circular references between packages did not always go down.

I don’t draw anything specific from either that work or the paper you cite here other than that we don’t know that the metrics we use are _necessarily_ useful, either in telling us what we think they tell us about the system or in whether being told those things is itself helpful.

Comment on Experimental Assessment of Software Metrics Using Automated Refactoring by Willem van den Ende

Willem van den Ende — Tue, 12 Feb 2013 20:42:23 +0000

do you mean the kind of metrics that are in tools like Sonar, and before that PMD? The problem I have with these metrics, is that they remind me most of the drunk man looking for his lost keys close to the lamp post, because that is where the light shines. The fact that we can measure things like cyclomatic complexities, LCOM and things like that because we can count lines of code and statements, does not mean they are the most effective way of seeing if a refactoring improves the design of existing code.
These days I’m looking more at things like: how fast can a team ship user visible improvements, how many defects are reported back per shipped feature (and what does it cost to fix), are developers happy to work on the code, can they communicate with their stakeholders in terms that are also present in the code (domain concepts etc.).

Comment on Experimental Assessment of Software Metrics Using Automated Refactoring by FelienneHermans

FelienneHermans — Tue, 12 Feb 2013 19:24:11 +0000

Thanks for your comment. This paper does not advocate the use of cohesion metrics or metrics in general or takes the stand that these metrics are more important than goods names.
It is simply the case that in many software projects metrics are used as an instrument and therefore is it worth to investigate whether they are conflicting or not, in a more serious way than ‘anyone knows it’. I totally agree with you that not all software engineering research is useful, but a deeper understanding of the relationship between metrics that are used in practice does not seem like effort wasted to me.

Comment on Experimental Assessment of Software Metrics Using Automated Refactoring by Willem van den Ende

Willem van den Ende — Tue, 12 Feb 2013 18:07:56 +0000

Sounds truly unimpressive. Anyone who’s applied metrics to actual codebases knows that many of our favorite metrics are conflicting and that some refactorings impact some more than others.
What is really stupifying is that the researchers apparently fail to understand that good naming (variables/methods/classes or whatever the important concepts in your language of choice are) trumps everything.
Prior art can be found in Koza’s book on genetic programming, where he does some automated refactorings on generated programs. The result is that the programs are slightly less un-understandable, but still pretty cryptic.

Comment on The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics by Experimental Assessment of Software Metrics Using Automated Refactoring - It Will Never Work in Theory

Tue, 12 Feb 2013 17:33:17 +0000

[...] impact and applicability of software metrics continues to be a subject of debate, especially since there are many metrics that measure similar properties, like cohesion. This [...]

Comment on Why We Need Evidence by Andrew McDowell

Andrew McDowell — Sun, 03 Feb 2013 14:09:43 +0000

I think version control is a particularly hard example to test because it is most valuable in recovering from rare accidents. I also think that it would be hard to convince people to stop requiring it because they would worry about those rare accidents. Possibly you could argue for its benefits by running experiments on how easy it was to recover from staged accidents and find out how often it was used in this way by looking in version control logs – much as you improve aircraft safety using a combination of test flights and black box analysis to learn as much as possible with as small a cost in lives as possible. On Friday I made a minor modification and found that the resulting script created a huge number of errors. Looking at the SVN log I saw that the errors were due to changes made by a member of staff not familiar with that script, and not in a position to test their changes easily. I reverted the changes, put in my changes, and later contacted that member of staff so that I could make and test the changes they needed. This was much easier than debugging the version they left in SVN.