These research questions are suggested to students of the PMBA course:
Q1: One of the methods to increase the quality of a software product is by reporting bugs found in it, so that the team can fix them. However, we believe that most software professionals consider bug reporting as a quality-decreasing activity. We conducted a survey, asking 100+ people about their perception of bug reporting, and analyzed the results. Published.
Q2: In proper project management, every person assigned to a task feels 100% responsible for its completion. This means that if the task fails, it is solely his/her fault. However, this is not what happens with most software developers. We conducted a survey, asking 100+ programmers about their attitude towards responsibility, and then analyzed the results. Published.
Q3: It’s a generally accepted truth that money doesn't motivate software professionals. Instead, other factors like technical complexity and team spirit motivate them. We decided to challenge this belief and conducted an experiment where we gave similar programming tasks to two groups of students. The first group was motivated by non-monetary rewards, while the second group was promised money for each successfully completed task. Afterwards, we analyzed the results.
Q4: It’s a well-known fact that the complexity of software decreases its quality. However, it seems that most programmers feel proud when their code is hard for other programmers to understand. In order to verify this, we conducted a survey asking 100+ programmers how they feel when their fellow coders have a hard time understanding their code. Then, we analyzed the result.
Q5: Lines of code is a metric that many software experts consider to be an inaccurate indicator of programmer productivity. We decided to challenge this belief and asked a group of programmers to review 100+ pull requests, which varied in terms of lines of code. We then asked them to tell us which pull request authors were more productive. After that, we analyzed the results.
Q6: It is obvious that the quality of bug reporting impacts the speed of bug fixing: the more accurate the report, the faster the team can fix the issue. We believe that most programmers don’t know how to report bugs correctly. In order to verify this belief, we conducted a survey, asking 100+ programmers to find problems in a few sample bug reports. Afterwards, we analyzed the results.
Q7: Having regular code reviews in a software team is considered a good practice that can improve the quality of code. However, some programmers may not feel comfortable when their code is being reviewed and criticized. We conducted a survey to validate this belief, asking 100+ programmers about their attitude toward peer reviews.
Q8: How comfortable are programmers in accepting their technical incompetence? How often do programmers say “No” to tasks assigned to them if they know they aren't skilled enough for them? We conducted a survey, asking 100+ programmers to react to tasks that are too complex for them. Afterwards, we analyzed the results.
Q9: There's a well-known problem with knowledge silos, where some programmers know too much about certain technical areas in the source code. This jeopardizes project maintainability and impedes knowledge transfer. However, many programmers seem to believe that it’s beneficial for them and the project if they retain a lot of knowledge and don’t share it. To validate this belief, we conducted a survey and then analyzed the results.
Q10: The PMBOK (Project Management Body of Knowledge) is a de-facto industry standard for project management that covers key areas of knowledge, including scope, cost, and risk management. It's generally expected that project managers in software projects are well-versed in PMBOK principles. To validate this assumption, we conducted a survey among 100+ managers from over 20 companies, asking them to complete a brief questionnaire assessing their level of familiarity with PMBOK. We then analyzed the results.
Q11: According to Samuel A. Culbert, a professor of management at the UCLA Anderson School of Management, performance reviews damage morale and hinder teamwork. To validate this claim, we conducted an experiment involving two groups of programmers assigned the same task. The performance of the first group was periodically reviewed, while the second group went unreviewed. After the task's completion, we interviewed the programmers and analyzed the outcomes.
Q12: Currently, Agile is the predominant management approach in software development. However, there's notable criticism of Agile, with some experts contending that its principles can be detrimental to projects. To understand this divergence in views, we surveyed 100+ software professionals about their stance on Agile practices and subsequently analyzed the results.
Q13: Self-managing organizations and teams purport not to have bosses. Instead, team members collectively pursue common goals, driven by an intrinsic motivation to succeed. It's often presumed that most programmers would relish such a boss-free environment. To validate this belief, we interviewed 100+ programmers about their preference regarding managerial oversight, then analyzed the responses.
Q14: Having a well-defined process can be advantageous for a software development project. Even within Agile teams, the procedures for writing code, reviewing changes, testing, and releasing can be structured. We conducted a survey, querying 100+ programmers across 20+ teams about their processes and their maturity levels. Subsequently, we analyzed the results.
Q15: When faced with technical challenges, programmers seek assistance from various sources: they may consult fellow programmers, pose questions on StackOverflow, refer to books, search the internet, or endeavor to resolve issues independently. To discern the most favored methods of obtaining assistance, we conducted a survey, asking 100+ programmers about their preferred avenues for help. Thereafter, we analyzed the results.
Q16: There might be a disparity between how programmers perceive their performance and productivity and the perspectives of their managers and peers, especially in the absence of a formal productivity evaluation mechanism. We initiated a survey, inquiring from programmers, their managers, and peers about their views on the programmers' recent performance. Following that, we analyzed the gathered data.
Q17: Trust is assumed to be a crucial element in team work, especially in solving complex software development issues. To gauge the level of trust among programmers and between managers and programmers, we conducted a survey of 100+ software practitioners. We then analyzed the data collected.
Q18: Measuring a software engineer's individual productivity is challenging, particularly given the industry's resentment toward performance evaluations. The main obstacle is the lack of reliable metrics that objectively gauge a coder's productivity. To identify metrics considered least harmful and most effective, we conducted a survey, asking 100+ software practitioners about their preferred metrics. We then analyzed the results.
Q19: The Definition of Done (DoD) is a cornerstone of the Scrum methodology, and it's expected that every programmer knows the exit criteria for each task. To verify this, we conducted a survey asking 100+ coders if they understand the DoD for their tasks and, if not, why. We then analyzed the results.