Margaret-Anne Storey

What I’m Hearing About Cognitive Debt (So Far)

Wed, 18 Feb 2026 00:00:00 +0000

A week ago, I wrote about how Generative and Agentic AI may be amplifying what I’ve been calling cognitive debt: the accumulated gap between a system’s evolving structure and a team’s shared understanding of how and why that system works and can be changed over time.

The post sparked thoughtful discussion across different communities. Rather than respond thread by thread, I want to synthesize what I’m hearing and connect it to other reflections I’ve been reading. I will likely update this as the conversation evolves.

A Growing Concern About Shared Understanding

Several practitioners, including Simon Willison and others on a Hacker News discussion of a Martin Fowler article, describe experiencing cognitive debt directly. They talk about getting lost in their own projects and finding it harder to confidently add new features. They can move faster, but they lose the deeper sensemaking that connects decisions to intent, and intent to code.

This is not just about code quality. It is about whether individual developers and product teams can maintain a coherent mental model of what the system is doing and why.

Across these discussions, one theme is consistent: velocity can outpace understanding.

Cognitive Debt Hurts Developers, Not Just the Software

Technical debt lives in the code.
Cognitive debt lives in people.

When shared understanding erodes, the pain shows up in:

Loss of confidence when making changes
Heavier review burden
Debugging friction
Slower onboarding
Stress and fatigue

The software may be “working”, but the theory of the system becomes harder to access and keep track of. The cost is not only structural. It is experiential.

Siddhant Khare has written about AI fatigue. Steve Yegge reflects on burnout emerging from AI-accelerated development. Annie Vella eloquently writes about the emotional and cognitive experience of uncertainty when systems become harder to reason about. These perspectives reinforce that this is not just an engineering discipline issue, but one that affects how developers feel and function.

Cognitive Debt, Like Technical Debt, Must Be Repaid

Martin Fowler notes that, like technical debt, cognitive debt must eventually be repaid. I agree.

But rebuilding lost knowledge requires restoring the distributed theory of the system. That includes capturing intent, the rationale behind decisions, key constraints, and how the architecture supports change.

That theory is not stored in code alone. It is distributed across:

People
Documentation
Tests
Conversations
Tooling
And increasingly, AI agents

Repayment means maintaining all of these, not just refactoring code or updating architecture documents.

Under pressure to move quickly, whether in startups racing to learn or in large organizations pushing AI adoption, that repayment can feel expensive and easy to defer.

“This Is Just Engineering”, But Incentives Are Changing

Several commenters, including Michael Würsch, argue that cognitive debt reflects a failure of good engineering discipline. Clear specifications, rigorous reviews, extensive testing, and explicit architecture documentation should prevent knowledge loss.

In principle, I agree. But in practice, the incentives are shifting. AI lowers the cost of producing structure. It becomes easier for structure to evolve faster than shared understanding can stabilize. Even disciplined teams must consciously throttle or shape their practices to keep understanding aligned with change.

Specifications and documents are not sufficient if they are not living artifacts that teams actively engage with.

Emerging Mitigation Strategies

Encouragingly, many readers shared how they are mitigating cognitive debt.

They describe:

More rigorous review practices
Writing tests that capture intent
Updating design documents continuously
Treating prototypes as disposable

Some also describe using AI to reduce the cost of these practices, and even to support cognitive tracking, dependency management, and explanation.

Used deliberately, AI may help make cognitive work more visible rather than obscuring it.

The Open Question: How Will High-Performing Teams Adapt?

High-performing teams have always managed technical debt intentionally. As AI is adopted by startups and large companies, the question becomes how teams will manage cognitive debt.

How will they shape socio-technical practices and tools to externalize intent and sustain shared understanding? How will they use Generative and Agentic AI not only to accelerate code production, but to maintain their collective theory?

As AI reduces technical friction, shared understanding may become the bottleneck on performance.

I am continuing to watch how this evolves. If you are seeing mitigation practices that work in real teams, I would love to learn from them.

How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt

Mon, 09 Feb 2026 00:00:00 +0000

The term technical debt is often used to refer to the accumulation of design or implementation choices that later make the software harder and more costly to understand, modify, or extend over time. Technical debt nicely captures that “human understanding” also matters, but the words “technical debt” conjure up the notion that the accrued debt is a property of the code and effort needs to be spent on removing that debt from code.

Cognitive debt, a term gaining traction recently, instead communicates the notion that the debt compounded from going fast lives in the brains of the developers and affects their lived experiences and abilities to “go fast” or to make changes. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.

Technical debt lives in the code; cognitive debt lives in developers' minds

Cognitive debt is likely a much bigger threat than technical debt, as AI and agents are adopted. Peter Naur reminded us some decades ago that a program is more than its source code. Rather a program is a theory that lives in the minds of the developer(s) capturing what the program does, how developer intentions are implemented, and how the program can be changed over time. Usually this theory is not just in the minds of one developer but fragments of this theory are distributed across the minds of many, if not thousands, of other developers.

I saw this dynamic play out vividly in an entrepreneurship course I taught recently. Student teams were building software products over the semester, moving quickly to ship features and meet milestones. But by weeks 7 or 8, one team hit a wall. They could no longer make even simple changes without breaking something unexpected. When I met with them, the team initially blamed technical debt: messy code, poor architecture, hurried implementations. But as we dug deeper, the real problem emerged: no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together. The code might have been messy, but the bigger issue was that the theory of the system, their shared understanding, had fragmented or disappeared entirely. They had accumulated cognitive debt faster than technical debt, and it paralyzed them.

This dynamic echoes a classic lesson from Fred Brooks’ Mythical Man-Month. Adding more agents to a project may add more coordination overhead, invisible decisions, and thus cognitive load. Of course, agents can also be used to manage cognitive load by summarizing what changes have been made and how, but the core constraints of human memory and working capacity will be stretched with the push for speed at all costs. The reluctance to slow down and to do the work that Kent Beck calls “make the hard change easy” is what will lead to cognitive debt and load in the future.

In a breakout session at a recent Future of Software Engineering Retreat (arranged by Martin Fowler and Thoughtworks) we discussed how developers need to slow down and use practices such as pair programming, refactoring, and test-driven development to address technical debt AND cognitive debt. By slowing down and following these practices, cognitive debt can also be reduced and shared understanding across developers and teams rebuilt.

But what can teams do concretely as AI and agents become more prevalent? First, they may need to recognize that velocity without understanding is not sustainable. Teams should establish cognitive debt mitigation strategies. For example, they may wish to require that at least one human on the team fully understands each AI-generated change before it ships, document not just what changed but why, and create regular checkpoints where the team rebuilds shared understanding through code reviews, retrospectives, or knowledge-sharing sessions.

Second, we need better ways to detect cognitive debt before it becomes crippling. Warning signs include: team members hesitating to make changes for fear of unintended consequences, increased reliance on “tribal knowledge” held by just one or two people, or a growing sense that the system is becoming a black box. These may be signals that the shared theory is eroding.

Finally, this phenomenon demands serious research attention. How do we measure cognitive debt? What practices are most effective at preventing or reducing it in AI-augmented development environments? How does cognitive debt scale across distributed teams or open-source projects where the “theory” must be reconstructed by newcomers? As generative and agentic AI reshape how software is built, understanding and managing cognitive debt may be one of the most important challenges our field faces.

I’ll be exploring these questions further in a keynote at the ICSE Technical Debt Conference and Panel. Cognitive debt tends not to announce itself through failing builds or subtle bugs after deployment, but rather shows up through a silent loss of shared theory. As generative and agentic AI accelerate development, protecting that shared theory of what the software does and how it can change may matter more for long-term software health than any single metric of speed or output.

Developer Productivity Working from Home during the Pandemic

Fri, 01 Oct 2021 12:30:00 +0000

Since the beginning of the pandemic I have studied developer productivity while working from home.

The following is one talk I gave as a keynote at ICGSE and ISSP 2021 (co-located with ICSE 2021)

After the Pandemic: Rethinking Developer Productivity (There’s more to it than you think) from Margaret-Anne Storey

The Who, What, How of Software Engineering Research

Tue, 01 Sep 2020 15:30:00 +0000

We recently published a paper that describes a framework to highlight human and social aspects in empirical software engineering research. This framework brings elements from the Design Science research we have done, research my student Courtney Williams did for her Master’s thesis, the keynote I gave at ICSE 2019, and a framework developed by McGrath and Runkel back in the 70s. We apply our Who-What-How framework to two paper venues in our community: papers published at ICSE 2017 and in the Springer Empirical Software Engineering Journal in 2017. The following shows the main elements in our framework and below you can find a teaser of the results we found from our analysis. In a nutshell, what we found is that although many papers aim at supporting developers or improving developer productivity, most papers do not directly involve developers in their research but rely on data.

The Who What How Framework:

Title:

The who, what, how of software engineering research: a socio-technical framework

Authors:

Margaret-Anne Storey, Neil A. Ernst, Courtney Williams & Eirini Kalliamvakou

Abstract:

Software engineering is a socio-technical endeavor, and while many of our contributions focus on technical aspects, human stakeholders such as software developers are directly affected by and can benefit from our research and tool innovations. In this paper, we question how much of our research addresses human and social issues, and explore how much we study human and social aspects in our research designs. To answer these questions, we developed a socio-technical research framework to capture the main beneficiary of a research study (the who), the main type of research contribution produced (the what), and the research strategies used in the study (how we methodologically approach delivering relevant results given the who and what of our studies). We used this Who-What-How framework to analyze 151 papers from two well-cited publishing venues—the main technical track at the International Conference on Software Engineering, and the Empirical Software Engineering Journal by Springer—to assess how much this published research explicitly considers human aspects. We find that although a majority of these papers claim the contained research should benefit human stakeholders, most focus predominantly on technical contributions. Although our analysis is scoped to two venues, our results suggest a need for more diversification and triangulation of research strategies. In particular, there is a need for strategies that aim at a deeper understanding of human and social aspects of software development practice to balance the design and evaluation of technical innovations. We recommend that the framework should be used in the design of future studies in order to steer software engineering research towards explicitly including human and social concerns in their designs, and to improve the relevance of our research for human stakeholders.

Citation:

Storey, M., Ernst, N.A., Williams, C. et al. The who, what, how of software engineering research: a socio-technical framework. Empir Software Eng 25, 4097–4129 (2020). https://doi.org/10.1007/s10664-020-09858-z Our paper is online at this link.

Teaser of the results!

A Theory of Developer Satisfaction and Perceived Productivity

Mon, 01 Jun 2020 15:30:00 +0000

We presented our TSE 2019 paper that describes a theory of developer productivity and satisfaction at ICSE 2020, the International Conference on Software Engineering, scheduled for Seoul, Korea. The research in this paper followed a three month sabbatical I spent working with the 1ES (one engineering system) at Microsoft in 2017 (lead by Jacek Czerwonka), collaborating with colleagues from Microsoft Research (Brendan Murphy, Tom Zimmermann and Chris Bird). A brief overview of the survey is shown below. Our online supplemental materials include the survey instrument.

Title:

Towards a Theory of Software Developer Job Satisfaction and Perceived Productivity

Authors:

Margaret-Anne Storey, Thomas Zimmermann, Christian Bird, Jacek Czerwonka, Brendan Murphy and Eirini Kalliamvakou

Abstract:

Developer satisfaction and work productivity are important considerations for software companies. Enhanced developer satisfaction may improve the attraction, retention and health of employees, while higher productivity should reduce costs and increase customer satis- faction through faster software improvements. Many researchers and companies assume that perceived productivity and job satisfaction are related and may be used as proxies for one another, but these claims are a current topic of debate. There are also many social and technical factors that may impact satisfaction and productivity, but which factors have the most impact is not clear, especially for specific development contexts. Through our research, we developed a theory articulating a bi-directional relationship between software developer job satisfaction and perceived productivity, and identified what additional social and technical factors, challenges and work context variables influence this relationship. The constructs and relationships in our theory were derived in part from related literature in software engineering and knowledge work, and we validated and extended these concepts through a rigorously designed survey instrument. We instantiate our theory with a large software company, which suggests a number of propositions about the relative impact of various factors and challenges on developer satisfaction and perceived productivity. Our survey instrument and analysis approach can be applied to other development settings, while our findings lead to concrete recommendations for practitioners and researchers.

Citation:

M. Storey, T. Zimmermann, C. Bird, J. Czerwonka, B. Murphy and E. Kalliamvakou, “Towards a Theory of Software Developer Job Satisfaction and Perceived Productivity,” in IEEE Transactions on Software Engineering, doi: 10.1109/TSE.2019.2944354. A preprint of our paper can be downloaded from this link.

Slides from our short presentation at ICSE:

Towards a Theory of Developer Satisfaction and Productivity from Margaret-Anne Storey

Video of our talk at ICSE 2020:

ICSE 2019 Keynote: Publish or Perish

Thu, 30 May 2019 15:30:00 +0000

I presented a keynote at ICSE’2019 (the International Conference on Software Engineering Engineering) in Montreal, Canada. In this talk I challenged our community to consider that although much of our research is aimed at improving developer productivity or supporting developers in some way, we often do not directly study human and social aspects in our empirical studies, bringing some aspects of the relevance of our research into question.

Title:

Publish or Perish: Questioning the Impact of Our Research on the Software Developer

Abstract:

How often do we pause to consider how we, as a community, decide which developer problems we address, or how well we are doing at evaluating our solutions within real development contexts? Many of our research contributions in software engineering can be considered as purely technical. Yet somewhere, at some time, a software developer may be impacted by our research. In this talk, I invite the community to question the impact of our research on software developer productivity. To guide the discussion, I first paint a picture of the modern-day developer and the challenges they experience. I then present 4+1 views of software engineering research — views that concern research context, method choice, research paradigms, theoretical knowledge and real-world impact. I demonstrate how these views can be used to design, communicate and distinguish individual studies, but also how they can be used to compose a critical perspective of our research at a community level. To conclude, I propose structural changes to our collective research and publishing activities — changes to provoke a more expeditious consideration of the many challenges facing today’s software developer.

Publish or Perish: Questioning the Impact of Our Research on the Software Developer from Margaret-Anne Storey

Using Visual Abstracts to Communicate and Promote Software Engineering Research (a first step!)

Thu, 09 Nov 2017 05:30:00 +0000

Today, I’m presenting a short paper at ESEM 2017 on research I conducted together with my colleagues at Lund University over the past year! We spent over a year reading and discussing papers on Design Science, to understand how design science may be a useful lens for understanding and reflecting on software engineering research. We furthermore suggest using a visual abstract template as a way to communicate software engineering research contributions through this design science lens. We see this as a first step in terms of the benefits of using a visual abstract in our community. Initial feedback has been very positive and we welcome feedback and ideas from others in the community.

Title:

Using a Visual Abstract as a Lens for Communicating and Promoting Design Science Research in Software Engineering

Authors:

Margaret-Anne Storey, Emelie Engstrom, Per Runeson, Martin Host, Elizabeth Bjarnason (Lund University, Sweden and University of Victoria, Canada)

Abstract:

Empirical software engineering research aims to generate prescriptive knowledge that can help software engineers improve their work and overcome their challenges, but deriving these insights from real-world problems can be challenging. In this paper, we promote design science as an effective way to produce and communicate prescriptive knowledge. We propose using a visual abstract template to communicate design science contributions and highlight the main problem/solution constructs of this area of research, as well as to present the validity aspects of design knowledge. Our conceptualization of design science is derived from existing literature and we illustrate its use by applying the visual abstract to an example use case. This is work in progress and further evaluation by practitioners and researchers will be forthcoming.

A preprint of our paper is available here. A template for the visual abstract can be found at github.com/margaretstorey/VASE, if you use it, please share your experience with us!

Thanks to Greg Wilson for suggesting the visual abstract idea to us.

Using a Visual Abstract as a Lens for Communicating and Promoting Design Science Research in Software Engineering from Margaret-Anne Storey

FSE 2016 Panel: The State of Software Engineering Research

Thu, 01 Dec 2016 12:30:00 +0000

The 2016 International Symposium on the Foundations of Software Engineering hosted a panel of prominent software engineering researchers moderated by Margaret-Anne Storey. The slides presented during the panel can be found here

This post builds on the summary written by Diomidis Spinellis and the video recording available on YouTube

Our panelists:

Tao Xie University of Illinois at Urbana-Champaign Tao is an ACM distinguished researcher. His Research focuses on automated software testing, mobile security, and software analytics.	Laurie Williams North Carolina State University Laurie is a founder of the Extreme Programming / Agile Conference. Her research focuses on software security, testing, and agile programming.
Peri Tarr IBM Research Peri is a principal research staff member at IBM TJ Watson Lab and a technical lead for Cognitive Tools and Methods at IBM. Her research focuses on software composition and aspect oriented software development.	Prem Devanbu University of California at Davis Prem started his career as an industrial software developer, then worked at Bell Labs and AT&T Research before beginning to teach at University of California at Davis. His research focuses on empirical software engineering, naturalness of software, and social analytics.

Lionel Briand
University of Luxembourg Lionel currently leads the Software Verification and Validation Lab at the University of Luxembourg. He strongly advocates that research is practical to industry.

Our panelists were asked to reflect on three questions related to research in software engineering:

Do you believe our community as a whole is achieving the right balance of science, engineering, and design in our combined research efforts?
What new or existing areas of research do you think our community should pay more attention to?
Do you have novel suggestions for how we could improve our research methods to increase the impact of software engineering research in the near and distant future?

Each panelist was asked to briefly present their thoughts on these questions. Then we opened the floor to questions, and the rest of the panel was dedicated to a discussion between panelists and members of the audience. Our summary of the panel discussion focuses on the panelist responses to the three questions posed as well as the themes that emerged from their responses.

Balancing Science and Engineering

A common theme that quickly emerged was the importance of the role of industry in research. To kickstart the group discussion, panelists were asked to reflect on a statement made by Jan Bosch of Chalmers University at a research conference a few weeks earlier:

“Research does not start in universities anymore, it starts in industry.”

A quick show of hands at the conference demonstrated that the majority of people in attendance seemed to agree with Jan Bosch’s claim. Williams also agreed with this statement and expanded it further by stating that “research starts in industry, because that’s the context”. Briand felt that because “we are in a discipline where most of the phenomenon we are studying cannot be reproduced in a lab environment”, as software engineers, “our lab is the industry”.

All panelists agreed that collaborating with practitioners (not only industry, but also open-source communities, governments, etc.) is essential to solve real problems. Williams drew connections between research in software engineering and biology:

“If we try to come up with problems that we think are interesting, that would be similar to a biologist never going outside. We have to go out there and see the problems that they have and then help with it.”

However, even if practitioners are aware of these problems, they may not be able to solve them. Briand mentioned that a lack of expertise and a lack of freedom to look at novel solutions might be to blame. Devanbu observed that researchers have this advantage:

“As a researcher, you can have a broader perspective that spans over several languages, and not only try to generalize observations, but also find effects that are only observable at an ecosystem level. It’s not only a question of freedom, but also of perspective that industrials don’t have because they are not considering different projects at the same time.”

Xie suggested we engage in practitioners in research that is currently outside of their scope:

“If we show [practitioners] things outside of their scope (that in the longer term may be important), they may be more open, and may engage in collaborations with academic researchers, […] along with providing data, problems, or discussions.”

Members of the audience, namely Daniel Jackson (Massachusetts Institute of Technology) and Tom Ball (Microsoft Research), emphasized that a balance is needed, and that looking at basic science should not be left out. Notable examples, such as UNIX, Simula, ALGOL 60, and distributed systems, were not the product of massive empirical studies, but of academic researchers sitting in a room and brainstorming.

The discussion above illustrates the importance of making a conscious effort to reach out to practitioners. However, this is not an easy task and it requires real commitment and patience from researchers, as Peri Tarr mentioned:

“One of the problems that we face all the time as industrial researchers is gaining the trust of the people whose problem we’re going to help them solve […]. It can take months or years to get on the same page with the people who have a problem, to establish that yes, you’re looking for a way to solve their problem that will actually work for them, within, as Lionel points out, their real-world constraints.”

The audience (at FSE and listening to the broadcast) questioned (via Twitter) about our role as researchers and how we collaborate with industry, for example:

More discussion on these questions is needed! We invite you to participate in the blog discussion below.

Paying Attention to Other Areas of Research

In their opening statements, all panelists mentioned other areas of research that our community should look at.

Devanbu mentioned DevOps and IoT as other areas that the SE community tends to neglect. Xie mentioned SE research results that had a broad impact outside of the SE community, such as symbolic execution, delta debugging, or Representational State Transfer (REST). Xie further suggested that we consider more of the societal impact of SE research, advocating for a “bigger social responsibility” for researchers. He referred to the previous day’s keynote from Margaret Burnett about gender inclusiveness of software, and cited David Notkin’s 2013 quote:

“Anybody who thinks that we are just here because we are smart forgets that we’re also privileged, and we have to extend that further. So we have got to educate and help every generation”

Williams addressed the problem of cybersecurity as one of the main challenges for our community, stating that “we haven’t yet provided software engineers the means to write secure code without impacting their own workflow.” She said that software engineering researchers need to “situate [their] work in this world where there is someone working against [them], whether it’s an attacker or someone doing something they aren’t supposed to.” The second research area Williams highlighted was “agile software development on steroids”; the world of continuous integration, continuous deployment, devOps, continuous experimentation, testing in production, etc. We need to explore ways of adopting these practices as well as understand their benefits and the risks they introduce.

Tarr insisted on focusing our research efforts at the intersection of Software Engineering and other “high impact, societally important, value creation areas”, such as health care, environment, cognitive sciences, security and privacy, and education. She said, “In every one of these areas, these people are trying to get new generations of software done, but they don’t know how to do it […]. We desperately need software engineers at the intersection of these areas.” She noted that the traditional areas of software engineering research are now being driven by practitioners and that, as researchers, we are privileged to have the opportunity to take bigger risks that lead to bigger rewards. We “shouldn’t be working in areas where we aren’t afraid to fail”.

Briand considers that, although all topics covered by our community are relevant to practitioners, our “research is largely disconnected from practical engineering needs and priorities” and we “fail to recognize the variations across domains and contexts”. The needs and constraints of people developing software across these varying domains are completely different and “there is no such things as a universal solution to any software engineering problem”. In the domain of software engineering, our working assumptions and contextual factors make a huge difference. Because there is a disconnect from particular needs and priorities, there is a gap in the research literature – “the gap between what I needed and what I could find was significant” – that is too large to deal with.

What are your thoughts on the panelists’ suggestions for future software engineering research directions? Do you agree or disagree? Or do you suggest other areas we should pay attention to, e.g., are there other disciplines we should apply our results to, as the tweet below suggests? Let us know in the discussion below!

Widening Our Vision of What is Research

While discussing whether we need to pay more attention to different areas of research, the panelists were asked to comment on Jane Cleland-Huang’s (University of Notre Dame) tweet regarding fostering more diverse areas of research:

Cleland-Huang commented on her tweet by adding:

“It is easy for us as a community to lock into the same area. For example a lot of people do research that benefits from open-source systems, but other areas [are left out], such as immersive studies in industry, or areas where I do research in, such as requirements and traceability, where datasets are not so available. If we want to make a difference in those areas, what do we, as a community, need to do in terms of the review process and encouraging that kind of research?”

As discussed in the previous sections, if we want to do impactful research, we need to reach out to practitioners and look at the intersection of software engineering and other fields. However, this cannot happen because if, as Xie mentions, we keep a “narrow-minded definition of what is a research contribution”, a large number of papers that may have a high impact on industry will not make it in our venues. Too often our community rejects contributions that look at real-world problems because it’s not research, it’s engineering. A notable example of this is William’s comment regarding her research on agile software development: “My research and the research my lab did was initially rejected by the community because they considered that practitioners shouldn’t do that (using agile methods). But they were doing it, so we have to accept what practitioners are doing on a widespread basis.”

Xie mentioned that “we don’t have enough expertise or experience in the program committees to really judge whether there is a real problem or not.” Tarr furthered this with, “As a community, one of the most important things that we can do is to […] start establishing norms and bars for people who are conducting high risk, important research in important places and are going out into the world to get this information.”

In response to a question posed by Storey regarding how we know when our methods have crossed the line from research to pure engineering, Williams gave the advice that when we are shifting more to the engineering side of things, we should take a step back and reframe the problem in a more scientific way. For example, we can ask “what are the independent variables?” that will allow us to switch to a scientific way of thinking about our research.

This discussion is related to one tweet we received ahead of the panel:

It would seem that our community may need to accept contributions that differ according to their engineering, scientific and design content, but if that is so, do we need to establish different criteria when assessing papers? Jonathan Bell suggested in a tweet that we consider not just evaluation approaches, but also our datasets and tools:

Finally, some discussion that occurred on Twitter suggests we rethink how our community considers negative results and that we look to how other research areas embrace not just positive results:

In summary, we wish to thank the conference organizers for suggesting this panel, and we thank the panelists and the FSE community for participating in this discussion! And we hope to continue the discussion in the comments below!

Matthieu Foucault, Carlene Lebeuf, and Margaret-Anne Storey - University of Victoria

Disrupting Programmer Productivity One Bot at a Time

Sun, 30 Oct 2016 12:30:00 +0000

I am giving a short talk at FSE 2016, and also a longer talk at CASCON 2016 on “Disrupting Developer Productivity One Bot at a Time”.

Thanks to Alexey Zagalsky and Carlene Lebeuf for their contributions to this talk! We also published a Visions paper at FSE 2016.

Abstract:

Conversational bots have become a popular addition to many mainstream platforms and software engineering has adopted them at an almost dizzying pace across every phase of the development life cycle. Bots reportedly help developers become more productive by automating tedious tasks, by bringing awareness of important project or community activities, and by reducing interruptions. Developers “talk to” and “listen to” these bots in the same conversational channels they use to collaborate with and monitor each other. However, the actual impact these bots have on developer productivity and project quality is still unclear. In this talk, I will give an overview of how bots play a prominent role in software development and discuss the benefits and challenges that can arise from relying on these “new virtual team members”. I will also explore how bots may influence other knowledge work domains and propose a number of future directions for practitioners and researchers to consider.

Cascon 2016 Keynote: Disrupting Developer Productivity One Bot at a Time from Margaret-Anne Storey