Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Mikhail Evtikhiev

dblp:288/0388 · DBLP profile ↗
← Back
4ranked-venue papers
2as first author
4since 2021 · last 2025
0000-0002-1004-8943ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 4 · 2 first-author · 4 since 2021Databases, data management, data science and information retrieval · 1 · 1 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
2 papers
Empirical software engineering · 73% Software maintenance and evolution · 27%
Human-computer interaction and pervasive computing
1 paper
Collaborative and social computing · 100%

Topics — the 3 heaviest of 5, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Empirical software engineering
developer studies
0.912025
What Could Possibly Go Wrong: Undesirable Patterns in Collective Development · ACM Trans. Softw. Eng. Methodol. 2025
Empirical software engineering
mining software repositories
0.712023
BFSig: Leveraging File Significance in Bus Factor Estimation · ESEC/SIGSOFT FSE 2023
Empirical software engineering › qualitative research
interview study
0.312025
What Could Possibly Go Wrong: Undesirable Patterns in Collective Development · ACM Trans. Softw. Eng. Methodol. 2025

Methods — techniques the papers use, named apart from their topics

survey · 1.7exploratory interviews · 1.7pagerank · 0.7graph metrics · 0.7betweenness centrality · 0.7
YearPublicationVenuePosition
2025 What Could Possibly Go Wrong: Undesirable Patterns in Collective Development
abstract
Software development, often perceived as a technical endeavor, is fundamentally a social activity requiring collaboration among team members. Acknowledging this, the software development community has devised strategies to address possible collaboration-related shortcomings. Various studies have attempted to capture the social dynamics within software engineering. These studies developed methods to identify numerous teamwork issues and proposed various approaches to address them. However, there is a need for a comprehensive bottom-up exploration from practitioner’s perceptions to common patterns. This article introduces the concept of undesirable patterns in collective development, referring to potential teamwork problems that may escalate if unaddressed. Through 38 in-depth exploratory interviews, we identify and classify 42 patterns, revealing their origins and consequences. To the best of our knowledge, some patterns, like Teamwork pipeline bottleneck , were never reported before. Subsequent surveys, 436 and 968 participants each, explore the significance and frequency of the undesirable patterns and evaluate potential tools and features to manage these patterns. The study contributes a nuanced understanding of undesirable patterns, evaluating their impact and proposing pragmatic tools and features for industrial application. The findings provide a valuable foundation for further in-depth studies and the development of tools to enhance collaborative software engineering practices.
Mikhail Evtikhiev, Ekaterina Koshchenko, Vladimir Kovalenko
ACM Trans. Softw. Eng. Methodol.1
2023 BFSig: Leveraging File Significance in Bus Factor Estimation
abstract
Software projects experience the departure of developers due to various reasons. As developers are one of the main sources of knowledge in software projects, their absence will inevitably result in a certain degree of knowledge depletion. Bus Factor (BF) is a metric to evaluate how this knowledge loss can affect the project’s continuity. Conventionally, BF is calculated as the smallest set of developers, removing over half the project knowledge upon departure. Current state-of-the-art approaches measure developers’ knowledge by the number of authored files, utilizing version control system (VCS) information. However, numerous studies have shown that files in software projects have different significance. In this study, we explore how weighting files according to their significance affects the performance of two prevailing BF estimators. We derive significance scores by computing five well-known graph metrics from the project’s dependency graph: PageRank, In-/Out-/All-Degree, and Betweenness Centralities. Furthermore, we introduce BFSig , a prototype of our approach. Finally, we present a new dataset comprising reported BF scores collected by surveying software practitioners from five prominent Github repositories. Our results indicate that BFSig outperforms the baselines by up to an 18% reduction in terms of Normalized Mean Absolute Error (NMAE). Moreover, BFSig yields 18% fewer False Negatives in identifying potential risks associated with low BF. Besides, our respondent confirmed BFSig versatility by showing its ability to assess the BF of the project’s subfolders. In conclusion, we believe to estimate BF from authorship, software components of higher importance should be assigned heavier weight. Currently, BFSig exclusively explores the topological characteristics of these components. Nevertheless, considering attributes such as code complexity and bug proneness could potentially enhance the performance of BFSig.
Vahid Haratian, Mikhail Evtikhiev, Pouria Derakhshanfar, Eray Tüzün, Vladimir Kovalenko
ESEC/SIGSOFT FSE2
2023 Out of the BLEU: How should we assess quality of the Code Generation models?
Mikhail Evtikhiev, Egor Bogomolov, Yaroslav Sokolov, Timofey Bryksin
J. Syst. Softw.1
2021 TNM: A Tool for Mining of Socio-Technical Data from Git Repositories
abstract
Networks of collaboration between engineers are reflected in traces of developers' activity in version control systems (VCSs). Extracting data from Git repositories is an essential task for researchers and practitioners working on socio-technical analysis, but it requires substantial engineering work. With increasing interest in analysing socio-technical data and applying it in practice, there are no flexible and easily reusable tools to retrieve socio-technical information from VCSs. With no common reusable toolkit existing for this task, the burden of mining diverts the focus of researchers from their core research questions.In this paper, we present TNM-an open-source tool for mining socio-technical data from Git repositories. TNM is fast, flexible, and easily extensible.TNM is available on GitHub: https://github.com/JetBrains-Research/tnm.
Nikolai Sviridov, Mikhail Evtikhiev, Vladimir Kovalenko
MSR2