Simulation games are designed to cultivate expertise and rehearse particular skill sets. To yield longitudinal effects, sequences of events must be crafted to yield intended learning outcomes, sometimes by focusing on particularly difficult situations and replaying variants. The present paper develops a logic-based approach for encoding the interrelation between action, events, and objects in a manner that allows the resulting scenario description to immediately be executed in a game development environment. This has the dual effect of decoupling the description of a scenario from the simulation platform itself, as well as supporting iterative and flexible development of learning content. To this end, we provide three interrelated components: First, we develop a scenario description language based on Answer Set Programming. The language is designed to allow an automated reasoner to deduce a schedule of the future events that are caused by an action taken in a given simulation environment. Second, we define a protocol for exchanging actions and computed futures between, respectively, the simulation environment and the external automated reasoner. Finally, as a proof of concept, we develop an Application Programming Interface (API) for the Unity Real-Time Development Platform that implements the protocol and offers a software framework for connecting the computed future events to concrete game objects. This allows the game to evolve coherently from the specification. We argue that the resulting system inherits capabilities for artificial commonsense reasoning from its declarative basis which are useful for reasoning about an evolving emergency incident or training scenario.

Context: There is considerable variation in the productivity of software developers. Better knowledge about this variation may provide valuable inputs for the design of skill tests and recruitment processes. Objective: This paper aims to identify properties of software development productivity distributions and gain insight into mechanisms that potentially explain these productivity differences. Method: Four data sets that contain the results of software developers solving the same programming tasks were collected. The properties of the productivity distributions were analyzed, the fits of different types of distributions to the productivity data were compared, and potential generative mechanisms that would lead to the types of distributions with the best fit to the productivity data were evaluated. Results: The coefficient of variance of the productivity of the software developers was, on average, 0.55, with the top 50% of developers having average productivity that was 2.44 times higher than the bottom 50% of developers. All productivity samples were right-skewed, with an average skew of 1.79. About 30% of the observed productivity variance was explained by non-systematic, i.e., within-developer, variance. The distributions with the best fit to the empirical productivity data were the lognormal and power-law-with-an-exponential-cutoff distributions. The analysis of the mechanisms leading to productivity differences found no support for the "rich-getting-richer" explanation proposed for other disciplines. Instead, it suggests a constant productivity difference with increasing experience. Conclusion: The substantial difference in productivity among software developers solving programming tasks indicates that a thorough evaluation of skill in the recruitment process can be rewarding. In particular, the long tail towards higher productivity values demonstrates the large gains that can be achieved by detecting and recruiting developers with very high productivity. More research is needed to understand the mechanisms leading to the large productivity differences.

Context: While prior software development effort estimation research has examined the properties of estimation error measures, there has not been much research on the properties of measures of estimation bias. Objectives: Improved measurement of software development effort estimation bias. Methods: Analysis of the extent to which measures of estimation bias meet the criterion that perfect estimates should result in zero bias. Results: Recommendations for measurement of estimation bias for estimates of the mean, median, and mode software development effort. The results include the recommendation to avoid a commonly used measure of effort estimation bias. Conclusion: Proper evaluation of estimation bias requires knowledge about the type of estimates evaluated, together with the selection of a measure of estimation bias that gives zero bias for perfect estimates of that type.