@article {Sayagh2020646, title = {Software Configuration Engineering in Practice Interviews, Survey, and Systematic Literature Review}, journal = {IEEE Transactions on Software Engineering}, volume = {46}, number = {6}, year = {2020}, note = {cited By 12}, pages = {646-673}, abstract = {Modern software applications are adapted to different situations (e.g., memory limits, enabling/disabling features, database credentials) by changing the values of configuration options, without any source code modifications. According to several studies, this flexibility is expensive as configuration failures represent one of the most common types of software failures. They are also hard to debug and resolve as they require a lot of effort to detect which options are misconfigured among a large number of configuration options and values, while comprehension of the code also is hampered by sprinkling conditional checks of the values of configuration options. Although researchers have proposed various approaches to help debug or prevent configuration failures, especially from the end users{\textquoteright} perspective, this paper takes a step back to understand the process required by practitioners to engineer the run-time configuration options in their source code, the challenges they experience as well as best practices that they have or could adopt. By interviewing 14 software engineering experts, followed by a large survey on 229 Java software engineers, we identified 9 major activities related to configuration engineering, 22 challenges faced by developers, and 24 expert recommendations to improve software configuration quality. We complemented this study by a systematic literature review to enrich the experts{\textquoteright} recommendations, and to identify possible solutions discussed and evaluated by the research community for the developers{\textquoteright} problems and challenges. We find that developers face a variety of challenges for all nine configuration engineering activities, starting from the creation of options, which generally is not planned beforehand and increases the complexity of a software system, to the non-trivial comprehension and debugging of configurations, and ending with the risky maintenance of configuration options, since developers avoid touching and changing configuration options in a mature system. We also find that researchers thus far focus primarily on testing and debugging configuration failures, leaving a large range of opportunities for future work. {\textcopyright} 1976-2012 IEEE.}, keywords = {Application programs, Bibliographies, Codes (symbols), Errors, Facebook, Interviews, Program debugging, Software algorithms, Software systems, Surveys, Systematics}, doi = {10.1109/TSE.2018.2867847}, url = {https://www.scopus.com/inward/record.uri?eid=2-s2.0-85052624554\&doi=10.1109\%2fTSE.2018.2867847\&partnerID=40\&md5=f1b2d51b59522e24e5c52f064a62d00b}, author = {Sayagh, M. and Kerzazi, N. and Adams, B. and Petrillo, F.} } @article {Sayagh20201259, title = {What should your run-time configuration framework do to help developers?}, journal = {Empirical Software Engineering}, volume = {25}, number = {2}, year = {2020}, note = {cited By 2}, pages = {1259-1293}, abstract = {The users or deployment engineers of a software system can adapt such a system to a wide range of deployment and usage scenarios by changing the value of configuration options, for example by disabling unnecessary features, tweaking performance-related parameters or specifying GUI preferences. However, the literature agrees that the flexibility of such options comes at a price: misconfigured options can lead a software system to crash in the production environment, while even in the absence of such configuration errors, a large number of configuration options makes a software system more complicated to deploy and use. In earlier work, we also found that developers who intend to make their application configurable face 22 challenges that impact their configuration engineering activities, ranging from technical to management-related or even inherent to the domain of configuration engineering. In this paper, we use a prototyping approach to derive and empirically evaluate requirements for tool support able to deal with 13 (primarily technical) configuration engineering challenges. In particular, via a set of interviews with domain experts, we identify four requirements by soliciting feedback on an incrementally evolving prototype. The resulting {\textquotedblleft}Config2Code{\textquotedblright} prototype, which implements the four requirements, is then empirically evaluated via a user study involving 55 participants that comprises 10 typical configuration engineering tasks, ranging from the creation, comprehension, refactoring, and reviewing of configuration options to the quality assurance of options and debugging of configuration failures. A configuration framework satisfying the four requirements enables developers to perform more accurately and more swiftly in 70\% and 60\% (respectively) of the configuration engineering tasks than a state-of-the-practice framework not satisfying the requirements. Furthermore, such a framework allows to reduce the time taken for these tasks by up to 94.62\%, being slower for only one task. {\textcopyright} 2020, Springer Science+Business Media, LLC, part of Springer Nature.}, keywords = {Computer software, Empirical studies, Engineering activities, Engineering challenges, Production environments, Quality assurance, Quality control, Run-time configuration, Run-time software, State of the practice, User study}, doi = {10.1007/s10664-019-09790-x}, url = {https://www.scopus.com/inward/record.uri?eid=2-s2.0-85078290351\&doi=10.1007\%2fs10664-019-09790-x\&partnerID=40\&md5=16acb880be24429edc0728ccce2169e2}, author = {Sayagh, M. and Kerzazi, N. and Petrillo, F. and Bennani, K. and Adams, B.} } @article {Sayagh2018, title = {Software Configuration Engineering in Practice: Interviews, Survey, and Systematic Literature Review}, journal = {IEEE Transactions on Software Engineering}, year = {2018}, doi = {10.1109/TSE.2018.2867847}, url = {https://www.scopus.com/inward/record.uri?eid=2-s2.0-85052624554\&doi=10.1109\%2fTSE.2018.2867847\&partnerID=40\&md5=f1b2d51b59522e24e5c52f064a62d00b}, author = {Sayagh, M. and Kerzazi, N. and Adams, B. and Petrillo, F.} } @conference {Sayagh2017255, title = {On cross-stack configuration errors}, booktitle = {Proceedings - 2017 IEEE/ACM 39th International Conference on Software Engineering, ICSE 2017}, year = {2017}, note = {cited By 0}, pages = {255-265}, abstract = {Today{\textquoteright}s web applications are deployed on powerful software stacks such as MEAN (JavaScript) or LAMP (PHP), which consist of multiple layers such as an operating system, web server, database, execution engine and application framework, each of which provide resources to the layer just above it. These powerful software stacks unfortunately are plagued by so-called cross-stack configuration errors (CsCEs), where a higher layer in the stack suddenly starts to behave incorrectly or even crash due to incorrect configuration choices in lower layers. Due to differences in programming languages and lack of explicit links between configuration options of different layers, sysadmins and developers have a hard time identifying the cause of a CsCE, which is why this paper (1) performs a qualitative analysis of 1,082 configuration errors to understand the impact, effort and complexity of dealing with CsCEs, then (2) proposes a modular approach that plugs existing source code analysis (slicing) techniques, in order to recommend the culprit configuration option. Empirical evaluation of this approach on 36 real CsCEs of the top 3 LAMP stack layers shows that our approach reports the misconfigured option with an average rank of 2.18 for 32 of the CsCEs, and takes only few minutes, making it practically useful. {\textcopyright} 2017 IEEE.}, doi = {10.1109/ICSE.2017.31}, url = {https://www.scopus.com/inward/record.uri?eid=2-s2.0-85027717403\&doi=10.1109\%2fICSE.2017.31\&partnerID=40\&md5=fa56524dafc8d93876ecd8c56f396da3}, author = {Sayagh, M. and Kerzazi, N. and Adams, B.} }