Publications

AI agents are increasingly collaborating to write, review, and deploy software, but we lack theory to explain what happens when many of them interact at scale. This paper applies complexity science to AI-native software ecosystems, drawing on the principle that large systems produce qualitatively new behaviours that cannot be predicted from their components alone. Seven falsifiable propositions bridge complexity theory to software evolution and open a new programme of empirical inquiry.

@misc{russo_2026_emergence, author = {Russo, Daniel}, title = {More Is Different: Toward a Theory of Emergence in {AI}-Native Software Ecosystems}, year = {2026}, eprint = {2604.19827}, archivePrefix = {arXiv}, primaryClass = {cs.SE}}

Most conferences are still one person talking at many people. Liberating structures — a set of facilitation techniques — flip that by getting everyone involved in structured dialogue. We tested them and found they build cross-disciplinary connections and help groups solve shared problems faster than traditional formats. If you run conferences or symposia and want people to actually talk to each other, this is a practical starting point.

@article{russo_2026_liberating, author = {Russo, Daniel and Storey, Margaret-Anne}, title = {From Passive to Participatory: {H}ow Liberating Structures Can Revolutionize Our Conferences}, journal = {Communications of the ACM}, year = {2026}, volume = {69}, number = {4}, pages = {28--31}}

Most AI transformations stall because organizations treat adoption as a technical problem when it’s really an organizational one. We mapped the barriers engineering teams actually hit when integrating generative AI, then distilled design principles from the teams that made it work. The patterns cut across domains — how to structure teams around AI, what to measure, and how to keep momentum once the novelty wears off.

@techreport{tavantzis_2025_challenge, author = {Tavantzis, Thodoris and Lambiase, Salvatore and Russo, Daniel and Feldt, Robert}, title = {From Challenge to Change: {D}esign Principles for {AI} Transformations}, institution = {arXiv}, year = {2025}}

Everyone is studying LLMs in software engineering now, but there’s no agreement on how to do it rigorously. These guidelines cover study design, execution, and reporting so that findings are actually reproducible. Also relevant if you’re running internal evaluations of AI tools and want to trust your own numbers.

@techreport{baltes_2025_guidelines, author = {Baltes, Sebastian and others}, title = {Guidelines for Empirical Studies in Software Engineering Involving Large Language Models}, institution = {arXiv}, year = {2025}}

Some developers pick up AI tools immediately; others ignore them entirely. We looked at why, and it turns out personality, prior experience, and team norms matter more than which tool you give people. Treating AI adoption as a rollout problem — same tool, same training, same timeline — misses the point. Teams vary, and adoption strategies should too.

@techreport{lambiase_2025_exploring, author = {Lambiase, Salvatore and Catolino, Gabriele and Palomba, Filipe and Ferrucci, Filipe and Russo, Daniel}, title = {Exploring Individual Factors in the Adoption of {LLM}s for Specific Software Engineering Tasks}, institution = {arXiv}, year = {2025}}

AI gets talked about as a productivity tool, but what does it do to creative thinking in software? Does it help developers explore new designs, or does it push everyone toward the same patterns? We don’t really know yet. This research agenda lays out the open questions — about design decisions, architectural thinking, and team-level innovation — that the field needs to answer.

@article{jackson_2025_creativity, author = {Jackson, Vanessa and Vasilescu, Bogdan and Russo, Daniel and Ralph, Paul and Izadi, Mohsen and Prikladnicki, Rafael and D'Angelo, Simone and Inman, Scarlett and Lisboa, Anita and van der Hoek, Andre}, title = {Creativity, Generative {AI}, and Software Development: {A} Research Agenda}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2025}, volume = {34}, number = {5}, pages = {1--28}}

When campuses closed in 2020, software engineering instructors tried everything — live lectures over Zoom, recorded videos, interactive labs. This study compares those approaches based on what students actually learned and retained. Synchronous and asynchronous formats each have trade-offs, and the data shows which ones matter most for hybrid program design.

@article{russo_2025_pandemic, author = {Russo, Daniel}, title = {Pandemic Pedagogy: {E}valuating Remote Education Strategies during {COVID-19}}, journal = {The Journal of Systems and Software}, year = {2025}, volume = {112392}, pages = {1--55}}

AI adoption doesn’t happen the same way everywhere. Teams in different regions adopt LLMs at different rates, and the reasons are cultural — organizational values, risk tolerance, communication norms. This study traces how those cultural dimensions shape trust and usage of generative AI in engineering work. Worth reading if you manage global teams and keep wondering why adoption looks so different across offices.

@article{lambiase_2025_cultural, author = {Lambiase, Salvatore and Catolino, Gabriele and Palomba, Filipe and Ferrucci, Filipe and Russo, Daniel}, title = {Investigating the Role of Cultural Values in Adopting Large Language Models for Software Engineering}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2025}, doi = {10.1145/3725529}}

Communities of practice fall apart when people don’t feel safe admitting what they don’t know. This study looks at what makes peer learning actually work in agile communities — and it comes down to specific team structures and leadership behaviors. The difference between a community where people share and one where they hide mistakes is smaller than you’d think.

@techreport{verwijs_2025_safe, author = {Verwijs, Christiaan and Acun-Roos, Esther and Russo, Daniel}, title = {Is It Safe To Learn And Share? {O}n Psychological Safety and Social Learning in {(A}gile{)} Communities of Practice}, institution = {arXiv}, year = {2025}}

The way people interact with a visualization — scrolling, filtering, linking — changes what they see in the data. Tested across multiple visualization types and tasks, and it turns out some interaction techniques genuinely help people spot patterns while others just add clicks. If you build dashboards, the interaction model matters more than you’d expect.

@article{van_berkel_2024_impact, author = {van Berkel, Niels and Tag, Benedikt and Jacobsen, Rasmus M. and Russo, Daniel and Purchase, Helen C. and Buschek, David}, title = {Impact of Interaction Technique in Interactive Data Visualisations}, journal = {The International Journal of Human-Computer Studies}, year = {2024}, volume = {192}, pages = {103359}}

Standard research methods assume the thing you’re studying holds still. AI, no-code platforms, and new development paradigms don’t. This playbook offers strategies for studying technologies that change the rules as they unfold — how to design studies that capture the mess of real adoption without sacrificing rigor. Written for researchers, but useful for anyone trying to make sense of a moving target.

@article{storey_2024_disruptive, author = {Storey, Margaret-Anne and Russo, Daniel and Novielli, Nicole and Kobayashi, Takashi and Wang, Denae}, title = {A Disruptive Research Playbook for Studying Disruptive Innovations}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2024}, volume = {33}, number = {8}, pages = {1--29}}

Too many teams pick an AI tool first and look for problems to solve with it second. This manifesto argues for the opposite: start with what people need, then decide if and how AI helps. It calls for evaluating AI tools not just on speed but on their effect on team well-being, learning, and autonomy. Drawn from research across multiple organizations and disciplines.

@article{russo_2024_manifesto, author = {Russo, Daniel and others}, title = {Generative {AI} in Software Engineering Must Be Human-Centered: {T}he Copenhagen Manifesto}, journal = {The Journal of Systems and Software}, year = {2024}, volume = {112115}, pages = {1--5}}

SAFe, LeSS, Scrum@Scale — organizations pick one and hope for the best, usually without evidence that it matters which. This large-scale study compares team effectiveness across these frameworks in real organizations. It turns out some scaling practices do correlate with better velocity, quality, and morale. The data can help directors and agile coaches stop guessing.

@article{verwijs_2024_agile, author = {Verwijs, Christiaan and Russo, Daniel}, title = {Do Agile Scaling Approaches Make A Difference? {A}n Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches}, journal = {Empirical Software Engineering}, year = {2024}, volume = {29}, pages = {75}}

A follow-up to the AI adoption study below, responding to methodological criticism. Tests alternate explanations, checks whether findings hold across subgroups, and shows the work behind the original claims. A case study in how reanalysis works in a contested research area.

@article{russo_2024_rcr_adopt, author = {Russo, Daniel}, title = {Navigating the Complexity of Generative {AI} Adoption in Software Engineering: {RCR} Report}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2024}, volume = {33}, number = {8}, pages = {1--5}}

AI adoption in software teams is messier than vendor slides suggest. Teams hit different bottlenecks — tool limitations, skill gaps, organizational readiness, unclear business value — and one-size-fits-all rollouts don’t work because of it. This study tracked teams through implementation to map where things stall and why. Useful for figuring out where your organization actually is in the adoption process, not where you think it is.

@article{russo_2024_adoption, author = {Russo, Daniel}, title = {Navigating the Complexity of Generative {AI} Adoption in Software Engineering}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2024}, volume = {33}, number = {5}, pages = {1--49}}

People assume well-being and productivity move together. The pandemic data says otherwise — they can diverge. A two-year longitudinal study tracking the same developers found that remote work setup, social connection, and workload balance mattered more for long-term output than hours logged.

@article{russo_2024_wellbeing, author = {Russo, Daniel and Hanel, Paul H. P. and van Berkel, Niels}, title = {Understanding Developers Well-Being and Productivity: {A} 2-Year Longitudinal Analysis during the {COVID-19} Pandemic}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2024}, volume = {33}, number = {3}, pages = {1--45}}

Responds to methodological questions about the longitudinal well-being study above. Clarifies the analysis, tests reliability across different time windows, and shows the core findings hold up.

@article{russo_2024_rcr_wellbeing, author = {Russo, Daniel and Hanel, Paul H. P. and van Berkel, Niels}, title = {Understanding Developers Well-Being and Productivity: {A} 2-Year Longitudinal Analysis during the {COVID-19} Pandemic: {RCR} Report}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2024}, volume = {33}, number = {3}, pages = {1--4}}

Diverse teams can outperform homogeneous ones, but only if conflict is handled well. Without psychological safety, diversity actually hurts — people suppress ideas instead of surfacing them. This study looks at how diversity, conflict, and safety interact in agile teams. The takeaway for team leads: building a diverse team is step one; creating norms where differences become useful is the harder part.

@article{verwijs_2024_diversity, author = {Verwijs, Christiaan and Russo, Daniel}, title = {The Double-Edged Sword Of Diversity: {H}ow Diversity, Conflict, and Psychological Safety Impact Agile Software Teams}, journal = {IEEE Transactions on Software Engineering}, year = {2024}, volume = {50}, number = {1}, pages = {1--16}}

Did forced remote work hurt developer performance? For most, no. We measured satisfaction and delivery in the same teams before and during lockdowns. Productivity held steady, and satisfaction actually went up for people with long commutes or caregiving duties. If your hybrid policy is still based on assumptions rather than data, this is the data.

@article{russo_2023_satisfaction, author = {Russo, Daniel and Hanel, Paul H. P. and Altnickel, Sylvia and van Berkel, Niels}, title = {Satisfaction and Performance of Software Developers during Enforced Work from Home in the {COVID-19} Pandemic}, journal = {Empirical Software Engineering}, year = {2023}, volume = {28}, pages = {53}}

“Hybrid” means different things to different teams. Some do two days in office, some are fully flexible, some split by role. This paper maps out the range of arrangements software teams actually use and identifies which models fit which team structures. Helpful for anyone designing a hybrid policy who wants to understand the trade-offs before committing.

@article{smite_2023_future, author = {Smite, Darja and Christensen, Erik and Tell, Per and Russo, Daniel}, title = {The Future Workplace: {C}haracterizing the Spectrum of Hybrid Work Arrangements for Software Teams}, journal = {IEEE Software}, year = {2023}, volume = {40}, number = {2}}

Scrum ceremonies that work fine in person can fall apart over video calls. This study identifies which practices broke down when teams went remote and which adaptations helped maintain velocity. Standups, retros, and planning sessions each needed different adjustments. Practical for Scrum masters figuring out what to change for distributed teams.

@article{cucolas_2023_impact, author = {Cucolaş, Alin Augustin and Russo, Daniel}, title = {The Impact of Working From Home on the Success of Scrum Projects: {A} Multi-Method Study}, journal = {Journal of Systems and Software}, year = {2023}, volume = {197}, pages = {111562}}

Recent critiques questioned whether Partial Least Squares (PLS) is a valid statistical method. We think the critics went too far. This response defends appropriate uses of PLS and clarifies where the criticism itself misses the mark. A short read for researchers trying to decide when PLS fits their study and when it doesn’t.

@article{russo_2023_pls, author = {Russo, Daniel and Stol, Klaas-Jan}, title = {Don't Throw the Baby Out With the Bathwater: {C}omments on 'Recent Developments in {PLS}'}, journal = {Communications of the Association for Information Systems}, year = {2023}, volume = {52}, pages = {1--4}}

Why do some Scrum teams thrive while others go through the motions? Checklists won’t tell you — the inputs, processes, and outcomes interact in ways that simple audits miss. This paper synthesizes research into a unified theory of what drives team effectiveness in Scrum, including threshold effects where changing one practice only helps if other conditions are already in place. Useful for diagnosing why a team is stuck rather than just adding more process.

@article{verwijs_2023_theory, author = {Verwijs, Christiaan and Russo, Daniel}, title = {A Theory of Scrum Team Effectiveness}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2023}, volume = {32}, number = {3}, pages = {1--52}}

Are personality differences between male and female software engineers similar to those found in the general population, or does the field attract a more uniform profile? This study measures traits like openness and agreeableness across genders and finds patterns that mirror broader research. The implications touch team dynamics, mentoring, and hiring — particularly the assumption that all engineers think and communicate the same way.

@article{russo_2022_gender, author = {Russo, Daniel and Stol, Klaas-Jan}, title = {Gender Differences in Personality Traits of Software Engineers}, journal = {IEEE Transactions on Software Engineering}, year = {2022}, volume = {48}, number = {3}, pages = {1--16}}

Finding real developers to participate in research is slow and expensive. Prolific, an online recruitment platform, makes it faster. This paper shares lessons from using it — how to screen participants, maintain study quality, and reach developers you wouldn’t find through your usual channels. A practical guide for researchers who need bigger, more diverse samples without the usual overhead.

@inproceedings{russo_2022_recruiting, author = {Russo, Daniel}, title = {Recruiting Software Engineers on {P}rolific}, booktitle = {Proceedings of the International Workshop on Recruiting Participants for Empirical Software Engineering (RoPES '22)}, publisher = {ACM}, address = {Pittsburgh, PA, USA}, month = {May}, year = {2022}}

Teams say they want curious developers, but how do you actually measure that? This study links personality traits to “need for cognition” — the drive to engage in effortful thinking. Curiosity and openness turn out to be stable predictors of who seeks out learning opportunities. Relevant for hiring and team composition if you care about more than just technical skill on paper.

@article{russo_2022_anecdote, author = {Russo, Daniel and Masegosa, Andres R. and Stol, Klaas-Jan}, title = {From Anecdote to Evidence: {T}he Relationship Between Personality and Need for Cognition of Developers}, journal = {Empirical Software Engineering}, year = {2022}, volume = {27}, pages = {71}}

Big agile transformations often stall because organizations change processes without changing leadership, culture, or skills. This mixed-methods study of one major transformation traces the sequence in which things need to happen for agile to actually stick. It identifies the common pitfalls and the conditions that separate transformations that deliver from those that just rebrand the status quo.

@article{russo_2021_agile, author = {Russo, Daniel}, title = {The Agile Success Model: {A} Mixed Methods Study of a Large-Scale Agile Transformation}, journal = {ACM Transactions on Software Engineering and Methodology}, year = {2021}, volume = {30}, number = {4}, pages = {1--45}}

PLS-SEM is widely used in software engineering research but often misapplied. This tutorial explains the method, walks through an example, and surveys how it has been used in published work. If you’re studying something complex — team dynamics, culture, adoption patterns — and considering PLS-SEM, start here.

@article{russo_2021_pls, author = {Russo, Daniel and Stol, Klaas-Jan}, title = {{PLS-SEM} for Software Engineering Research: {A}n Introduction and Survey}, journal = {ACM Computing Surveys}, year = {2021}, volume = {54}, number = {4}, pages = {1--37}}

What counts as rigorous empirical work in software engineering? Depends who you ask — there’s been no consensus. This living document sets standards for case studies, controlled experiments, surveys, and qualitative research, with checklists for both reviewers and researchers. Also useful outside academia for anyone trying to judge whether a study’s claims hold water.

@techreport{ralph_2021_standards, author = {Ralph, Paul and others}, title = {Empirical Standards for Software Engineering Research}, institution = {SIGSOFT}, year = {2021}, note = {Version 0.2.0}}

The pandemic gave us a rare chance to study developer well-being and productivity with before-and-during data. We tracked the same developers across the lockdown period, measuring workload, isolation, management style, and team connection. Some people thrived; some didn’t. The differences came down to specific team practices and individual factors — not just personality or job title.

@article{russo_2021_predictors, author = {Russo, Daniel and Hanel, Paul H. P. and Altnickel, Sylvia and van Berkel, Niels}, title = {Predictors of Well-being and Productivity among Software Professionals during the {COVID-19} Pandemic: {A} Longitudinal Study}, journal = {Empirical Software Engineering}, year = {2021}, volume = {26}, pages = {62}}

When an algorithm makes a decision about someone — hiring, promotion, performance review — how you explain it changes whether they trust it. Different explanation styles produce different reactions, even when the underlying model is identical. Some explanations build confidence; others raise suspicion. Worth reading before deploying any ML model where people are on the receiving end.

@inproceedings{van_berkel_2021_effect, author = {van Berkel, Niels and Goncalves, Jorge and Russo, Daniel and Hosio, Simo and Skov, Marianne B.}, title = {Effect of Information Presentation on Fairness Perceptions of Machine Learning Predictors}, booktitle = {Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems (CHI '21)}, publisher = {ACM}, address = {Yokohama, Japan}, month = {May}, year = {2021}}

How did developers actually spend their days during lockdown? We documented daily routines, which activities changed most, and how that affected both work and home life. One surprising finding: work-home boundaries blurred for some people and clarified for others, depending on living situation and personal preference. A detailed look at what pandemic work patterns actually looked like on the ground.

@inproceedings{russo_2021_daily, author = {Russo, Daniel and Hanel, Paul H. P. and Altnickel, Sylvia and van Berkel, Niels}, title = {The Daily Life of Software Engineers during the {COVID-19} Pandemic}, booktitle = {Proceedings of the 2021 International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP '21)}, publisher = {IEEE}, address = {Madrid, Spain}, month = {May}, year = {2021}}

In financial systems, “quality” means different things to different teams, which makes it hard to measure or compare across groups. This paper builds an ontology — a shared vocabulary — for quality dimensions specific to financial software. The semantic model lets tools interpret quality metrics consistently and reason about trade-offs. Useful for organizations trying to align quality definitions across distributed teams.

@article{ciancarini_2020_squapon, author = {Ciancarini, Paolo and Nuzzolese, Andrea Giovanni and Presutti, Valentina and Russo, Daniel}, title = {{SQuAP-Ont}: {A}n Ontology of Software Quality Relational Factors from Financial Systems}, journal = {Semantic Web Journal}, year = {2020}, volume = {11}, number = {6}, pages = {1--15}}

Open source teams have always worked iteratively, but few use formal agile frameworks. This paper looks at what happens when you bring agile ceremonies and tools to distributed, volunteer-driven communities. Some practices translate well; others need adaptation. Written for open source maintainers thinking about how to add more structure without killing the culture.

@inproceedings{ciancarini_2020_opensource, author = {Ciancarini, Paolo and Missiroli, Michele and Poggi, Fabio and Russo, Daniel}, title = {An Open Source Environment for an Agile Development Model}, booktitle = {Proceedings of the 2020 Open Source Software Conference (OSS '20)}, publisher = {Springer}, address = {Innopolis, Russian Federation}, month = {May}, year = {2020}}

Technical debt piles up until it becomes a bottleneck, and by then the conversation with business stakeholders is usually adversarial. This model connects technical debt decisions to strategic goals and organizational capacity, giving teams a framework for deciding what to fix now and what can wait. Also helps engineers talk about debt in terms business partners actually care about.

@inproceedings{ciancarini_2020_debt, author = {Ciancarini, Paolo and Russo, Daniel}, title = {The Strategic Technical Debt Management Model: {A}n Empirical Proposal}, booktitle = {Proceedings of the 2020 Open Source Software Conference (OSS '20)}, publisher = {Springer}, address = {Innopolis, Russian Federation}, month = {May}, year = {2020}}

Most CS programs teach coding and teamwork as separate things, even though real engineering requires both at once. Cooperative thinking is a framework that integrates computational thinking with collaborative problem-solving from day one. Students taught this way build stronger teams and write more maintainable code. The paper lays out the framework and the evidence behind it.

@article{ciancarini_2019_cooperative, author = {Ciancarini, Paolo and Missiroli, Michele and Russo, Daniel}, title = {Cooperative Thinking: {A}nalyzing a New Framework for Software Engineering Education}, journal = {Journal of Systems and Software}, year = {2019}, volume = {157}, pages = {110401}}

Studying culture, motivation, and team dynamics with strict hypothesis testing often flattens out the interesting stuff. But pure exploration doesn’t scale. Soft theory is a pragmatic middle ground — it lets researchers study messy, emergent phenomena without abandoning rigor. Written for anyone doing quantitative work on the social side of software engineering.

@inproceedings{russo_2019_soft, author = {Russo, Daniel and Stol, Klaas-Jan}, title = {Soft Theory: {A} Pragmatic Alternative to Conduct Quantitative Empirical Studies}, booktitle = {Proceedings of the 2019 IEEE International Symposium on Empirical Software Engineering and Measurement (CESSER-IP '19)}, publisher = {IEEE}, address = {Montreal, Canada}, month = {May}, year = {2019}}

Computational thinking courses tend to focus on algorithms and logic in isolation. Adding agile practices — sprints, retros, pair programming — helps students learn how real teams solve problems under constraints. This paper describes how to do it and what changes in student learning when you connect classroom exercises to industry ways of working.

@inproceedings{ciancarini_2019_exploiting, author = {Ciancarini, Paolo and Missiroli, Michele and Russo, Daniel}, title = {Exploiting Agile Practices to Teach Computational Thinking}, booktitle = {Proceedings of the 2019 DevOps Conference (DEVOPS '19)}, publisher = {Springer}, address = {Chateau de Villebrumier, France}, month = {May}, year = {2019}}

Every financial institution defines software quality a little differently, shaped by risk tolerance, regulation, and operational complexity. This mixed-method study identifies the quality dimensions that cut across organizations and builds a meta-model that accounts for both the metrics people track and the expectations they don’t write down. Aimed at IT leaders trying to align quality standards across departments or evaluate vendors on what actually matters.

@article{russo_2018_metamodel, author = {Russo, Daniel and Ciancarini, Paolo and Falasconi, Tommaso and Tomasi, Marco}, title = {A Meta Model for Information Systems Quality: {A} Mixed-Study of the Financial Sector}, journal = {ACM Transactions on Management Information Systems}, year = {2018}, volume = {9}, number = {3}, pages = {1--38}}

Fifty years of Turing Award laureates tell a story about what the computing field valued at different moments. This essay reflects on how the award criteria have shifted over time and what those shifts reveal about the direction of the field. Written for anyone curious about how computing defines its own pantheon.

@article{russo_2018_turing, author = {Russo, Daniel}, title = {50 anni di Premio Turing: una Riflessione}, journal = {Mondo Digitale}, year = {2018}, volume = {76}, pages = {1--10}, note = {In Italian}}

Instead of sending students to companies, this program brings industry professionals into the classroom to work alongside students on real projects. The inverted model accelerates learning and builds interest in ways that traditional internships don’t. Describes the experience and what educators can take from it when building school-industry partnerships.

@article{missiroli_2018_developers, author = {Missiroli, Michele and Russo, Daniel and Ciancarini, Paolo and Torricelli, Paolo}, title = {Developers' Week: {A}lternanza Scuola-Lavoro Rovesciata}, journal = {Mondo Digitale}, year = {2018}, volume = {77}, pages = {1--10}, note = {In Italian}}

Choreographic programming defines interactions from a global perspective rather than wiring services together point-to-point. ChIP is a process for integrating choreographic designs with existing systems incrementally. It reduces integration errors and improves maintainability. Relevant for architects working with microservices who want a cleaner way to think about system-level interaction.

@inproceedings{giallorenzo_2018_chip, author = {Giallorenzo, Saverio and Lanese, Ivan and Russo, Daniel}, title = {{ChIP}: {A} Choreographic Integration Process}, booktitle = {Proceedings of the 2018 International Conference on Cooperative Information Systems (CoopIS '18)}, publisher = {Springer}, address = {Valletta, Malta}, month = {October}, year = {2018}}

Government contracts want fixed scope and detailed specs upfront. Agile wants the opposite. This paper examines how public sector organizations have structured procurement to allow iterative delivery without losing accountability. The lessons apply to anyone working in heavily regulated or contract-driven environments, not just government.

@inproceedings{russo_2018_contracting, author = {Russo, Daniel and Taccogna, Gabriele and Ciancarini, Paolo and Messina, Andrea and Succi, Giancarlo}, title = {Contracting Agile Developments for Mission Critical Systems in the Public Sector}, booktitle = {Proceedings of the 2018 International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIS '18)}, publisher = {ACM}, address = {Gothenburg, Sweden}, month = {May}, year = {2018}}

User stories work for most software, but mission-critical systems have domain logic too complex for a few lines on an index card. This paper brings knowledge engineering into the agile process — capturing and reasoning about complex requirements without abandoning iterative delivery. Aimed at teams in complex domains who keep building the wrong thing despite following the process.

@inbook{ciancarini_2018_agile, author = {Ciancarini, Paolo and Messina, Andrea and Poggi, Fabio and Russo, Daniel}, title = {Agile Knowledge Engineering for Mission Critical Software Requirements}, booktitle = {Synergies Between Knowledge Engineering and Software Engineering}, publisher = {Springer}, pages = {151--171}, year = {2018}}

A conceptual model for integrating computational thinking with collaborative problem-solving in software education. The idea: teach coding and teamwork together from the start rather than treating them as separate skills. Short poster format laying out the framework for curriculum design.

@inproceedings{russo_2018_poster, author = {Russo, Daniel and Missiroli, Michele and Ciancarini, Paolo}, title = {Poster: {A} Conceptual Model for Cooperative Thinking}, booktitle = {Proceedings of the 2018 International Conference on Software Engineering (ICSE '18)}, publisher = {ACM}, address = {Gothenburg, Sweden}, month = {May}, year = {2018}}

Computational thinking and agile both center on problem-solving, but they rarely meet in the classroom. This paper explores what happens when you combine them — using iterative, team-based methods to teach thinking skills. Students exposed to both learn to design systems others can build on and maintain, not just systems that work in isolation.

@inproceedings{missiroli_2017_cooperative, author = {Missiroli, Michele and Russo, Daniel and Ciancarini, Paolo}, title = {Cooperative Thinking, or: {C}omputational Thinking Meets Agile}, booktitle = {Proceedings of the 2017 IEEE Conference on Software Engineering Education and Training (CSEE\&T '17)}, publisher = {IEEE}, address = {Savannah, GA, USA}, month = {November}, year = {2017}}

Students know they should write tests first; they just don’t. The mindset shift is harder than the technical skill. This paper analyzes where students stumble and proposes techniques that build the habit by connecting testing to design thinking rather than treating it as a chore. Practical for programming instructors trying to make test-first stick.

@inproceedings{missiroli_2017_teaching, author = {Missiroli, Michele and Russo, Daniel and Ciancarini, Paolo}, title = {Teaching Test-First Programming: {A}ssessment and Solutions}, booktitle = {Proceedings of the 2017 IEEE International Conference on Computer Software and Applications (COMPSAC '17)}, publisher = {IEEE}, address = {Turin, Italy}, month = {July}, year = {2017}}

Italian banks run legacy systems under heavy regulation, and their quality concerns look different from the rest of the software industry. Compliance, continuity, and data integrity dominate. The interesting finding: there’s a meta-level concern — the quality of quality management itself. If your quality process is broken, measuring quality doesn’t help much.

@inproceedings{russo_2017_quality, author = {Russo, Daniel and Ciancarini, Paolo and Falasconi, Tommaso and Tomasi, Marco}, title = {Software Quality Concerns in the Italian Bank Sector: {T}he Emergence of a Meta-Quality Dimension}, booktitle = {Proceedings of the 2017 IEEE/ACM 39th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP '17)}, publisher = {IEEE}, address = {Buenos Aires, Argentina}, month = {May}, year = {2017}}

Younger engineers respond to agile practices differently than their predecessors. This comparative study identifies which ceremonies and practices resonate with millennials and where generational expectations around autonomy, feedback, and career growth diverge. Useful for teams noticing that one-size-fits-all agile isn’t landing the same way with everyone.

@inproceedings{missiroli_2017_agile, author = {Missiroli, Michele and Russo, Daniel and Ciancarini, Paolo}, title = {Agile for Millennials: {A} Comparative Study}, booktitle = {Proceedings of the 2017 IEEE/ACM 39th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP '17)}, publisher = {IEEE}, address = {Buenos Aires, Argentina}, month = {May}, year = {2017}}

Resilient systems handle failure gracefully. Antifragile systems get better from it. This paper applies antifragility — the idea that some systems gain capability under stress — to software architecture. It’s a different design philosophy from fault tolerance: instead of just surviving volatility, the system should improve from it. Early-stage thinking aimed at architects working in unpredictable environments.

@article{russo_2017_antifragile, author = {Russo, Daniel and Ciancarini, Paolo}, title = {Towards Antifragile Software Architectures}, journal = {Procedia Computer Science}, year = {2017}, volume = {109}, number = {C}, pages = {930--935}}

Scrum or Waterfall for project-based courses? This comparison looks at learning outcomes, student satisfaction, and skill development under both approaches. The answer depends on what you’re optimizing for — the two models build different competencies. Aimed at educators designing project courses.

@article{missiroli_2017_didattica, author = {Missiroli, Michele and Russo, Daniel and Ciancarini, Paolo}, title = {Didattica per Progetti a Confronto: Meglio {S}crum o {W}aterfall?}, journal = {Mondo Digitale}, year = {2017}, volume = {70}, pages = {1--10}, note = {In Italian}}

Developers copy code all the time without thinking about copyright, liability, or licensing. Sometimes that’s fine; sometimes it’s not. This paper walks through when code reuse is legally safe, when attribution is required, and where the real risks are. Written so both development teams and legal counsel can navigate the same conversation.

@inproceedings{ciancarini_2016_cloning, author = {Ciancarini, Paolo and Russo, Daniel and Sillitti, Alberto and Succi, Giancarlo}, title = {A Guided Tour of the Legal Implications of Software Cloning}, booktitle = {Proceedings of the 2016 International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIS '16)}, publisher = {ACM}, address = {Austin, TX, USA}, month = {May}, year = {2016}}

Can agile methods work in a high school CS class? This study tested it and found that students respond well — iterative, team-based learning builds both competence and confidence faster than traditional approaches. A straightforward case for bringing agile concepts into secondary education.

@inproceedings{missiroli_2016_learning, author = {Missiroli, Michele and Russo, Daniel and Ciancarini, Paolo}, title = {Learning Agile Software Development in High School: {A}n Investigation}, booktitle = {Proceedings of the 2016 International Conference on Software Engineering: Software Engineering Education and Training (ICSE-SEET '16)}, publisher = {ACM}, address = {Austin, TX, USA}, month = {May}, year = {2016}}

The more you design for stability, the more brittle the system gets. This manifesto proposes the opposite: value optionality, adaptability, and learning from stress. Instead of predicting what will go wrong and building walls around it, design systems that improve when exposed to volatility. A philosophical reframe with practical implications for architecture decisions.

@article{russo_2016_manifesto, author = {Russo, Daniel and Ciancarini, Paolo}, title = {A Proposal for an Antifragile Software Manifesto}, journal = {Procedia Computer Science}, year = {2016}, volume = {83}, number = {1}, pages = {982--987}}

Publishing data doesn’t make it usable. Quality issues — completeness, accuracy, timeliness — block analysis and erode trust, and in open data contexts you can’t control how data is produced or used. This roadmap frames quality as something to manage and communicate about, not just measure. Aimed at data teams and government agencies publishing open data.

@inproceedings{ciancarini_2016_bigdata, author = {Ciancarini, Paolo and Poggi, Fabio and Russo, Daniel}, title = {Big Data Quality: {A} Roadmap for Open Data}, booktitle = {Proceedings of the 2016 IEEE International Conference on Big Data Service (BigDataService '16)}, publisher = {IEEE}, address = {Oxford, UK}, year = {2016}}

Reverse engineering sits in a legal gray zone — sometimes necessary for maintenance or interoperability, sometimes a liability. This paper clarifies when it’s permissible and when it’s not, across different jurisdictions. Useful as a reference before starting any reverse engineering work where legal risk is a question.

@inproceedings{ciancarini_2016_reverse, author = {Ciancarini, Paolo and Russo, Daniel and Sillitti, Alberto and Succi, Giancarlo}, title = {Reverse Engineering: {A} Legal Perspective}, booktitle = {Proceedings of the 2016 ACM Symposium on Applied Computing (SAC '16)}, publisher = {ACM}, address = {Pisa, Italy}, month = {April}, year = {2016}}

Defense procurement defaults to proprietary software, but open source can meet security, reliability, and long-term support requirements in some contexts. This paper examines where open source makes sense in defense and where it doesn’t. A balanced analysis for procurement officers weighing the trade-offs.

@inproceedings{russo_2016_defense, author = {Russo, Daniel}, title = {Benefits of Open Source Software in Defense Environments}, booktitle = {Proceedings of the 2016 Software Engineering and Dependable Architectures (SEDA '16) Conference}, publisher = {Springer}, address = {Rome, Italy}, month = {May}, year = {2016}}

Italian public agencies adapted their procurement to support agile delivery — no small feat in a system designed for waterfall. This case study details the contracting and governance changes that made it work without losing oversight. The lessons transfer to other heavily regulated environments where procurement wasn’t designed with iteration in mind.

@inproceedings{russo_2016_public, author = {Russo, Daniel and Taccogna, Gabriele and Ciancarini, Paolo}, title = {Contracting Agile Developments for the Public Sector: {T}he Italian Case}, booktitle = {Proceedings of the 2016 Software Engineering and Dependable Architectures (SEDA '16) Conference}, publisher = {Springer}, address = {Rome, Italy}, month = {May}, year = {2016}}

What if you could predict quality issues or schedule risk from your own project’s historical data? This paper proposes using ML to learn patterns from a team’s actual development rhythm — not generic rules, but models trained on your data. Early-stage work on how data-driven planning might give teams earlier warning of problems.

@inproceedings{russo_2016_machine, author = {Russo, Daniel and Lomonaco, Vincenzo and Ciancarini, Paolo}, title = {A Machine Learning Approach for Continuous Development}, booktitle = {Proceedings of the 2016 Software Engineering and Dependable Architectures (SEDA '16) Conference}, publisher = {Springer}, address = {Rome, Italy}, month = {May}, year = {2016}}

Agile-based programming courses build collaborative skills and faster iteration cycles compared to traditional lecture-and-lab formats. This paper describes how to structure such courses and what changes in student outcomes. For educators looking to bring industry practices into the classroom without losing flexibility.

@article{missiroli_2016_didattica, author = {Missiroli, Michele and Russo, Daniel and Ciancarini, Paolo}, title = {Una Didattica {A}gile per la Programmazione}, journal = {Mondo Digitale}, year = {2016}, volume = {15}, number = {64}, pages = {1--10}, note = {In Italian}}

Agile and mission-critical software look incompatible — one values change, the other demands predictability. This paper argues they can coexist when agile is paired with the right governance and testing rigor. Written for defense and aerospace teams who want to modernize their development process without lowering the bar on assurance.

@article{messina_2016_paradigm, author = {Messina, Andrea and Fiore, Francesco and Ruggiero, Marco and Ciancarini, Paolo and Russo, Daniel}, title = {A New Agile Paradigm for Mission Critical Software Development}, journal = {The Journal of Defence Software Engineering (CrossTalk)}, year = {2016}, volume = {29}, number = {6}, pages = {25--30}}