Software Development and Platform Adoption as Successive Games of Real Options Investment and Valuation

Platform based software engineering is at the heart of a new mode software product development in the context of software ecosystems. In this setting, an organization develops a software platform with the intention of providing that platform for use and extension by software-producing organizations. Multiple benefits arise from engaging in platform-based software engineering from both the perspective of the platform developer and the software product developer, including decreased time to market, defrayed cost of development and increased software quality. Organizations have been engaging in platform-based software engineering for years, exemplified by cases such as Eclipse, Android and SAP. However, the body of research that studies software ecosystems and platform-based software engineering is still growing, with many areas still requiring further investigation. One such area is decision-making support for software platform adoption. Platform adoption, more strategically significant than simple acquisition and use of third party libraries, represents a reciprocal relationship between the software platform developer and the product developer. This relationship, and the products developed from the platform, may be long-lived, necessitating a close relationship between the platform developer and the product developer. Thus, platform adoption is strategic, rather than tactical, in nature. Little research exists that investigates decision making in the context of software platform adoption. While the research community is cognizant of prominent decision support criteria for software platform adoption, including licensing, hardware and operating systems compatibility, little research attempts to quantify the benefits afforded to the software platform developer, and even less that investigates the benefits realized by adopting organizations who produce software products based on a software platform. This work is the first stage in a long term research plan for quantifying the cost and earned value of engaging in platform-based software engineering from the perspective of a software product developer adopting a software platform. We have illustrated the adoption decision through two scenarios that exemplify strategic concerns raised in software platform adoption. The central assumption of this work is that software platform adoption reduces the cost of software development while increasing the earned value of the software product being built. Using this central theory, we propose a model for quantifying the cost and earned value of a platform-based software development. This model views software development as a series of decisions, or rather options, concerned with the decision of whether to engage or halt software development. Our model utilizes the Black-Scholes model for options evaluation. The research illustrates utilization of stochastic Monte Carlo simulation in order to perform experimentation on our underlying model as applied to our scenarios. From this research, we intend to develop theory from our simulation results that helps support strategic decision making in the context of the software ecosystems surrounding the platform and products

Software Development: Cowboy or Samurai

Much has been written about the failure of software development projects. The importance of good software to business cannot be underestimated. A major issue is quality of the software being written and produced. Over the years, the emphasis for improvement in software development has been to change the process. Unified Modeling Language is but one of a long line of changes in software development process starting with structured programming introduced in the seventies to object oriented programming in nineties. However, several software development experts have begun to assert that the problem may not be with the process employed but rather the human asset, namely the software developer. This paper discusses two extremes of software developer behaviors. These two ends of the spectrum are the cowboy, free of restrictions, and the Samurai, following a strict code of behavior. The paper first presents the characteristics of the cowboy and the Samurai then the paper compares the development environment within which each behavior is suitable. The paper concludes with a summary and industry observations

THE CAVES Project - Collaborative Analysis Versioning Environment System; THE CODESH Project - Collaborative Development Shell

A key feature of collaboration in science and software development is to have a {\em log} of what and how is being done - for private use and reuse and for sharing selected parts with collaborators, which most often today are distributed geographically on an ever larger scale. Even better if this log is {\em automatic}, created on the fly while a scientist or software developer is working in a habitual way, without the need for extra efforts. The {\tt CAVES} and {\tt CODESH} projects address this problem in a novel way, building on the concepts of {\em virtual state} and {\em virtual transition} to provide an automatic persistent logbook for sessions of data analysis or software development in a collaborating group. A repository of sessions can be configured dynamically to record and make available the knowledge accumulated in the course of a scientific or software endeavor. Access can be controlled to define logbooks of private sessions and sessions shared within or between collaborating groups.Comment: 4 pages, presented at the Meeting of the Division of Particles and Fields of the APS, Riverside, USA, August 200

Consequences of Unhappiness While Developing Software

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding the positive side of happiness -- positive emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that also studying the negative side -- unhappiness -- could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, and is mainly expressed in terms of development productivity and software quality. In this paper, we attempt to uncover the experienced consequences of unhappiness among software developers. Using qualitative data analysis of the responses given by 181 questionnaire participants, we identified 49 consequences of unhappiness while doing software development. We found detrimental consequences on developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data, will spawn new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.Comment: 6 pages. To be presented at the Second International Workshop on Emotion Awareness in Software Engineering, colocated with the 39th International Conference on Software Engineering (ICSE'17). Extended version of arXiv:1701.02952v2 [cs.SE

Easier Debugging of Multithreaded Software

Software activation is a technique designed to avoid illegal use of a licensed software. This is achieved by having a legitimate user enter a software activation key to validate the purchase of the software. Generally, a software is a single-threaded program. From an attacker’s perspective, who does not wish to pay for this software, it is not hard to reverse engineer such a single threaded program and trace its path of execution. With tools such as OllyDbg, the attacker can look into the disassembled code of this software and find out where the verification logic is being performed and then patch it to skip the verification altogether. In order to make the attacker’s task difficult, a multi-threaded approach towards software development was proposed [1]. According to this approach, you should break the verification logic into several pieces, each of which should run in a separate thread. Any debugger, such as OllyDbg, is capable of single-stepping through only one thread at a time, although it is aware of the existence of other threads. This makes it difficult for an attacker to trace the verification logic. Not just for an attacker, it is also difficult for any ethical developer to debug a multithreaded program. The motivation behind this project is to develop the prototype of a debugger that will make it easer to trace the execution path of a multi-threaded program. The intended debugger has to be able to single-step through all of the threads in lockstep

A Natural Language Interface for Code Search

One common task of developing or maintaining software is searching the source code for information like specific method calls or write accesses to certain fields. This kind of information is required to correctly implement new features and to solve bugs. This paper presents an approach for querying source code with a natural language interface. It enables the developer to execute a huge range of precise searches while being as easy and intuitive to use as writing natural language. The evaluation shows that the prototype implementation, integrated with the Eclipse development environment for Java, supports a wide range of queries and is able to correctly understand most real developer queries

Individual differences limit predicting well-being and productivity using software repositories : a longitudinal industrial study

Reports of poor work well-being and fluctuating productivity in software engineering have been reported in both academic and popular sources. Understanding and predicting these issues through repository analysis might help manage software developers' well-being. Our objective is to link data from software repositories, that is commit activity, communication, expressed sentiments, and job events, with measures of well-being obtained with a daily experience sampling questionnaire. To achieve our objective, we studied a single software project team for eight months in the software industry. Additionally, we performed semi-structured interviews to explain our results. The acquired quantitative data are analyzed with generalized linear mixed-effects models with autocorrelation structure. We find that individual variance accounts for most of the R-2 values in models predicting developers' experienced well-being and productivity. In other words, using software repository variables to predict developers' well-being or productivity is challenging due to individual differences. Prediction models developed for each developer individually work better, with fixed effects R-2 value of up to 0.24. The semi-structured interviews give insights into the well-being of software developers and the benefits of chat interaction. Our study suggests that individualized prediction models are needed for well-being and productivity prediction in software development.Peer reviewe