Comments for It Will Never Work in Theory

Comment on Automatic Patch Generation Learned from Human-Written Patches by Daniel Sobral

Daniel Sobral — Thu, 06 Jun 2013 23:28:28 +0000

About 25% on an academic study? It sounds promising to me. I’d like to know if PAR produced patches for _all_ bugs, or if there were bugs for which PAR decided it didn’t know how to fix. Ultimately, it might be cheaper to let software propose a patch, code review it, and then either accept the proposed patch or work on one on your own.

Comment on Automatic Patch Generation Learned from Human-Written Patches by Rodrigo

Rodrigo — Thu, 06 Jun 2013 17:57:54 +0000

Very interesting approach. My concern however, is how often the generated patches are just workarounds instead of fixes.

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.