We describe our experience with the migration of a diagramming tool written in Java from Swing to JavaFX. The experience led to unexpected realizations about the impact of differences in framework design and documentation.
Electronic version of the Chapter 39 in the book "40 Editions of ICSE". We discuss our attempts to retain the conference’s standards while tackling the reviewing load, to increase conference attendance, and to ensure that the Latin American software engineering community benefited.
If the Threats section in software engineering paper is here to stay, let's give it a fair shake. Individual Threats sections vary wildly in terms of quality. How can we efficiently improve the standard?
About anyone who develops with software technology will need some sort of documentation. The only problem is that producing it cost-efficiently is mission impossible.
Why don't we explicitly consider how expensive a particular design decision will be to capture and maintain consitent with the code, before adopting it?
What is the best way to capture architectural knowledge? There probably isn't any one answer to that question, but there are certainly many answers to the question of how project teams currently capture this kind of knowledge...
The ICSE 2017 Call for Research Papers is out, and there has been some discussion on social media and through email on the fact that submissions to the research track are limited to three papers per author...
If a university class is video-recorded, why bother showing up? Celebrated Canadian playwright Robert Lepage might have one answer: to commune, and be an influential part of the academic picture...
One of the reviews for my ICSE 2015 submission included the demand: "There is no threats to validity or limitation section. Please add this." When reporting on research results, it is of course necessary to state and discuss decisions of the experimental design that have major repercussions on how the results can be interpreted...
When reporting on data analyzed using a qualitative research approach, a major challenge is to properly indicate the nature and amount of the evidence that support a given observation...
A lot of the documents we need to understand and use software technologies include code examples... To decide whether to study a code example in detail, it's useful to have a summary of what it's about, just like for any other document. But most techniques for summarizing "normal" documents don't apply to code...
A flat (non-hierarchical) content presentation mostly assumes the reader wants to read everything sequentially. This assumption is fine for suspenseful novels, but it crumples in the case of API documentation...
Much effort is currently invested to increase our understanding of software development by analyzing large data sets [...]. This type of effort is now known as Software Analytics [...]. We [provide] a list of desirable practices for reporting on software analytics projects.
APIs are not always self-explanatory, so we need to complement them with documentation for better usability...But how do we do that? ...