What makes a great “grand challenge”?

Ten years ago DARPA, the US defense research agency, first organized the DARPA Grand Challenge. The challenge was to build a car that could drive 150 miles through the Mohave desert autonomously. The key is the car’s autonomy: No human brain was to steer it and make decisions, it was computers and other technology all the way. The associated technical challenges were manifold: read and interpret the environment correctly, predict behavior of the environment and the car while interacting, plan the route and get to the goal fastest, don’t kill anyone on the way. In its second attempt in 2005, the challenge was first fulfilled and won by the team of Sebastian Thrun of Stanford University.

Since then a series of other “grand challenges” has followed, some of which were reasonable, some of them less so. Here is what I think makes a great grand challenge:

  1. It is relevant for society and a non-expert recognizes the relevance
  2. It is cross-disciplinary, combining many different problems into one
  3. It is a useful application with a clear tangible communicable result
  4. It is measurable and achievable so that we know it when we solved it

I would avoid any “grand challenge” that an expert recognizes but not a layman. A grand challenge needs to stir emotions. Looking at example grand challenges proposed around the Internet, I find many too abstract, too focused on disciplinary issues. My vote goes to “the secure cell phone” as a grand challenge, but there are many others.

M.B.A.s or Engineers for Product Management?

I teach product management at a public German engineering school, where I am a professor of computer science. Product management is my nod towards “business informatics”, otherwise I only teach engineering courses (and one general how-to-perform-research class).

There is an old debate as to who makes better product managers: M.B.A.s or engineers? Having worked on both sides of the fence and having gotten both degrees, I can confirm that as so often, the question is wrong: A hiring manager for a product management position needs to focus on skills and attitude, not on degree credentials. The degree may be an indicator of such skills, but it is not a sufficient indicator.

Continue reading

Where to focus a university incubator

Fueled by the success of Silicon Valley startups and other success stories, there probably isn’t a single university today which would not like to foster startups from their student ranks. There is a lot to be said about how to do that, but before all operational decisions, a university incubator needs to know where to focus, and this is easy to get wrong.

The figure above shows my thinking on a key aspect of the subject: The type of student to spend your efforts on. A university incubator should focus on those students (and teach them and make it easier) who are sitting on the fence. It should ignore those whole will never do it and it should neglect those who will always find a way, no matter what.

For Posteriority and Reuse

FIWare is a large EU-sponsored program. It has mission (“about”) statement. Specifically:

FIWare is an open initiative aiming to create a sustainable ecosystem to grasp the opportunities that will emerge with the new wave of digitalization caused by the integration of recent Internet technologies. […]

Continue reading

From Developer Networks to Verified Communities: A Fine-Grained Approach

Abstract: Effective software engineering demands a coordinated effort. Unfortunately, a comprehensive view on developer coordination is rarely available to support software-engineering decisions, despite the significant implications on software quality, software architecture, and developer productivity. We present a fine-grained, verifiable, and fully automated approach to capture a view on developer coordination, based on commit information and source-code structure, mined from version-control systems. We apply methodology from network analysis and machine learning to identify developer communities automatically. Compared to previous work, our approach is fine-grained, and identifies statistically significant communities using order-statistics and a community-verification technique based on graph conductance. To demonstrate the scalability and generality of our approach, we analyze ten open-source projects with complex and active histories, written in various programming languages. By surveying 53 open-source developers from the ten projects, we validate the authenticity of inferred community structure with respect to reality. Our results indicate that developers of open-source projects form statistically significant community structures and this particular view on collaboration largely coincides with developers’ perceptions of real-world collaboration.

Keywords: Open source, social network analysis, developer networks, developer communities, respository mining, conductance

Reference: Mitchell Joblin, Wolfgang Mauerer, Sven Apel, Janet Siegmund, Dirk Riehle. “From Developer Networks to Verified Communities: A Fine-Grained Approach.” In Proceedings of the 37th International Conference on Software Engineering (ICSE 2015). IEEE Press, to appear.

The paper is available as a PDF file.

How Developers Acquire FLOSS Skills

Abstract: With the increasing prominence of open collaboration as found in free/libre/open source software projects and other joint production communities, potential participants need to acquire skills. How these skills are learned has received little research attention. This article presents a large-scale survey (5,309 valid responses) in which users and developers of the beta release of a popular file download application were asked which learning styles were used to acquire technical and social skills. We find that the extent to which a person acquired the relevant skills through informal methods tends to be higher for free/libre/open source code contributors, while being a professional software developer does not have this effect. Additionally, younger participants proved more likely to make use of formal methods of learning. These insights will help individuals, commercial companies, educational institutions, governments and open collaborative projects decide how they promote learning.

Keywords: Competencies, informal learning, non-formal learning, open source, skills, software developer

Reference: Ann Barcomb, Michael Grottke, Jan-Philipp Stauffert, Dirk Riehle, Sabrina Jahn. “How Developers Acquire FLOSS Skills.” In Proceedings of the 11th International Conference on Open Source Systems (OSS 2015). Springer Verlag, to appear.

The paper is available as a PDF file.

Improving Traceability of Requirements through Qualitative Data Analysis

Abstract: Traceability is an important quality aspect in modern software development. It facilitates the documentation of decisions and helps identifying conflicts regarding the conformity of one artifact to another. We propose a new approach to requirements engineering that utilizes qualitative research methods, which have been well established in the domain of social science. Our approach integrates traceability between the original documentation and the requirements specification and the domain model and glossary and supports adaptability to change.

Keywords: Requirements analysis, requirements traceability, qualitative data analysis

Reference: Andreas Kaufmann, Dirk Riehle. “Improving Traceability of Requirements through Qualitative Data Analysis.” In Proceedings of the 2015 Software Engineering Konferenz (SE 2015). Springer Verlag. Pages 165-170.

The paper is available as a PDF file.