This document summarizes the findings of a study that interviewed 59 experienced software engineers at Microsoft to understand the attributes of great software engineers. The study identified 53 attributes that were organized into internal personal characteristics and abilities of engineers, as well as external impacts engineers have on people, products, and users. Some of the most important internal attributes included being passionate about their work, continuously improving skills, and having strong practical decision-making abilities. Externally, great engineers applied their skills to create high-quality, elegant software and formed trusting relationships with teammates. The study provided insights and definitions for each attribute based on the interviews.
Requirement engineering is a key ingredient for software development to be effective. Apart from the
traditional software requirement which is not much appropriate for new emerging software such as smart
handheld device based software. In many perspectives of requirement engineering, traditional and new
emerging software are not similar. Whereas requirement engineering of traditional software needs more
research, it is obvious that new emerging software needs methodically and in-depth research for improved
productivity, quality, risk management and validity. In particular, the result of this paper shows that how
effective requirement engineering can improve in project negotiation, project planning, managing feature
creep, testing, defect, rework and product quality. This paper also shows a new methodology which is
focused on users work process applicable for eliciting the requirement of traditional software and any new
type software of smart handheld device such as iPad. As an example, the paper shows how the methodology
will be applied as a software requirement of iPad-based software for play-group students.
Analysing Attrition in Outsourced Software Projectcsandit
Information systems (IS) outsourcing has grown as a major business phenomenon, and widely
accepted as a business tool. Software outsourcing companies provide expertise, knowledge and
capabilities to their clients by taking up the projects both onsite and offsite. These companies
face numerous challenges including attrition of project members. Attrition is a major challenge
experienced by the outsourcing companies as it has severe impact on business, revenues and
profitability. In this paper, attrition data of a major software outsourcing company was
analysed and an attempt to find the reason for attrition is also made. The data analysis was
based on the data collected by an outsourcing company over a period of two years for a major
client. The results show that the client initiated attrition can have an impact on project and the
members quit the outsourcing company due to client initiated ramp down without revealing the
reason.
Distributed Software Development Process, Initiatives and Key Factors: A Syst...zillesubhan
Geographically Distributed Software Development (GSD) process differs from Collocated Software Development (CSD) process in various technical aspects. It is empirically proven that renowned process improvement initiatives applicable to CSD are not very effective for GSD. The objective of this research is to review the existing literature (both academia and industrial) to identify initiatives and key factors which play key role in the improvement and maturity of a GSD process, to achieve this goal we planned a Systematic Literature Review (SLR) following a standard protocol. Three highly respected sources are selected to search for the relevant literature which resulted in a large number of TOIs (Title of Interest). An inter-author custom protocol is outlined and followed to shortlist most relevant articles for review. The data is extracted from this set of finally selected articles. We have performed both qualitative and quantitative analysis of the extracted data to obtain the results. The concluded results identify several initiatives and key factors involved in GSD and answer each research question posed by the SLR.
Requirement engineering is a key ingredient for software development to be effective. Apart from the
traditional software requirement which is not much appropriate for new emerging software such as smart
handheld device based software. In many perspectives of requirement engineering, traditional and new
emerging software are not similar. Whereas requirement engineering of traditional software needs more
research, it is obvious that new emerging software needs methodically and in-depth research for improved
productivity, quality, risk management and validity. In particular, the result of this paper shows that how
effective requirement engineering can improve in project negotiation, project planning, managing feature
creep, testing, defect, rework and product quality. This paper also shows a new methodology which is
focused on users work process applicable for eliciting the requirement of traditional software and any new
type software of smart handheld device such as iPad. As an example, the paper shows how the methodology
will be applied as a software requirement of iPad-based software for play-group students.
Analysing Attrition in Outsourced Software Projectcsandit
Information systems (IS) outsourcing has grown as a major business phenomenon, and widely
accepted as a business tool. Software outsourcing companies provide expertise, knowledge and
capabilities to their clients by taking up the projects both onsite and offsite. These companies
face numerous challenges including attrition of project members. Attrition is a major challenge
experienced by the outsourcing companies as it has severe impact on business, revenues and
profitability. In this paper, attrition data of a major software outsourcing company was
analysed and an attempt to find the reason for attrition is also made. The data analysis was
based on the data collected by an outsourcing company over a period of two years for a major
client. The results show that the client initiated attrition can have an impact on project and the
members quit the outsourcing company due to client initiated ramp down without revealing the
reason.
Distributed Software Development Process, Initiatives and Key Factors: A Syst...zillesubhan
Geographically Distributed Software Development (GSD) process differs from Collocated Software Development (CSD) process in various technical aspects. It is empirically proven that renowned process improvement initiatives applicable to CSD are not very effective for GSD. The objective of this research is to review the existing literature (both academia and industrial) to identify initiatives and key factors which play key role in the improvement and maturity of a GSD process, to achieve this goal we planned a Systematic Literature Review (SLR) following a standard protocol. Three highly respected sources are selected to search for the relevant literature which resulted in a large number of TOIs (Title of Interest). An inter-author custom protocol is outlined and followed to shortlist most relevant articles for review. The data is extracted from this set of finally selected articles. We have performed both qualitative and quantitative analysis of the extracted data to obtain the results. The concluded results identify several initiatives and key factors involved in GSD and answer each research question posed by the SLR.
IT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERSijseajournal
The study intended to unravel critical IT project showstoppers which tend to halt IT projects temporarily or permanently, and ultimately cause them to fail, by positioning them in the systems development life cycle (SDLC) framework. Interviewing 8 IT project and program managers of the banking and telecommunications industries in Ghana individually and in a group, 19 critical showstoppers were identified spanning the whole SDLC. Generally, it was observed that for the successful completion of IT projects, the expertise and availability of project managers and team members are critical. Again, the project manager must be able to prove that the project is in line with the objectives and strategic direction of the business, is being mounted to gain competitive advantage, and has a solid business case. Thirdly, funding is key at all stages of the cycle, as well as approval for continuation at various stages.
It is impossible to separate the human factors from software engineering expertise during
software development, because software is developed by people and for people. The intangible
nature of software has made it a difficult product to successfully create, and an examination of
the many reasons for major software system failures show that the reasons for failures
eventually come down to human issues. Software developers, immersed as they are in the
technological aspect of the product, can quickly learn lessons from technological failures and
readily come up with solutions to avoid them in the future, yet they do not learn lessons from
human aspects in software engineering. Dealing with human errors is much more difficult for
developers and often this aspect is overlooked in the evaluation process as developers move on
to issues that they are more comfortable solving. A major reason for this oversight is that
software psychology (the softer side) has not developed as extensively
These days, organizations battle to get by in a worldwide rivalry. Each organization tries to locate the best rationality which is appropriate with their procedure to increase any and each favorable position among their opponents. Organizations ought to be more centered around understanding their own particular structure as far as procedures whether they are in the creation or administration division. The point and extent of this venture is to distinguish the requirements in development extend working condition. On the off chance that requirements are better comprehended at the beginning, it is trusted that better execution can be guaranteed. Distinguishing and expelling imperatives from bottleneck exercises help to decrease instabilities in development procedures and builds the straightforwardness of venture administration. This investigation was done in light of writing audit and a poll study. The information for this examination will be assembling through a point by point poll overview. The poll shape is sent to different development enterprises through email and in individual. The targets of the examination is to effectively lessen the imperatives which will diminish the superfluous wastage and loss of both cash and time due to deficient arranging.
EMPIRICAL STUDY OF THE EVOLUTION OF AGILE-DEVELOPED SOFTWARE SYSTEM IN JORDAN...ijbiss
The focus of agile in software development methods and practices. How to take effective methods in use
have received less attention. Especially in a large organization is not a little to take in agile methods to use.
This paper discusses the adoption and level of experience of the use of agile practices in three companies
in the software development company wide contacts in Jordan. The more practices that relied on largescale
flexibility to measure the progress made by the code work, that the developers efforts to the task of
estimating, to the use of coding standards, and the lack of overtime continuous, has a team to develop their
own operations, to use the limited documentation, and to have the team in one place facility. The adoption
of agile practices of the test, any test of the first unit tests and automated, and low. Some can only appear
agile practices without the adoption of a conscious, because developers find them useful. So it seems that
an emergency operation aimed at agility may also neglect the important agile practices.
Working software measures the progress. Basically, Agile method involves interleaving the specification, implementation, design and testing. Series of versions are developed with the involvement of and evaluation by the stake holders in each version. Agile methods aim at reducing the software process overheads (like documentation) and concentrate more on code rather than the design. Customer involvement, incremental delivery, freedom of developers to evolve new working methods, change management, and last but not the least simplicity is the basic essence of Agile development. Agile methodologies are well suited for small as well as medium sized projects.
http://essaysreasy.com .That's a sample paper - essay / paper on the topic "Information systems engineering" created by our writers!
Disclaimer: The paper above have been completed for actual clients. We have acclaimed personal permission from the customers to post it.
Lindorff Group is a leading outsourced receivables management company in Europe, and one of the leading on a global basis. For the past three–four years, they have increasingly adopted agile practices, especially in a large scale project converting and improving an old system written in Powerhouse to new .Net–technology.
The results from adopting agile practices have been mostly positive, however, there were challenging issues related to requirement handling and estimation that needed attention. In 2008, Lindorff joined a project with Symphonical funded by Innovation Norway. The purpose of the project was to develop software for requirements handling, estimation and knowledge management for the Symphonical platform. Symphonical is a flexible web–based collaboration platform, where users can brainstorm, plan, organize and coordinate any process.
This talk presents results from a case study detailing the challenges faced by Lindorff as they simultaneously adopted agile practices and introduced a new system for requirement handling and estimation. According to the respondents of the case study, Lindorff appears to have improved on two of the main points of concern presented in the 2007 study: requirement handling and estimation. Many users report that the introduction of agile methods and the platform Symphonical has improved the quality of important work processes. Furthermore, they report that the introduction of Symphonical has provided a framework for structured discussions regarding individual requirements, which helps maintaining the focus of IT projects. Furthermore, the flexible sharing regime where one can easily share information to external participants improves the effectiveness and efficiency of collaboration with all project contributors.
ITERATIVE AND INCREMENTAL DEVELOPMENT ANALYSIS STUDY OF VOCATIONAL CAREER INF...ijseajournal
Software development process presents various types of models with their corresponding phases required to be accordingly followed in delivery of quality products and projects. Despite the various expertise and skills of systems analysts, designers, and programmers, systems failure is inevitable when a suitable development process model is not followed. This paper focuses on the Iterative and Incremental Development (IID)model and justified its role in the analysis and design software systems. The paper adopted the qualitative research approach that justified and harnessed the relevance of IID in the context of systems analysis and design using the Vocational
Career Information System (VCIS) as a case study. The paper viewed the IID as a change-driven software development process model. The results showed some system specification, functional specification of system and design specifications that can be used in implementing the VCIS using the IID model. Thus, the paper concluded that in systems analysis and design, it is imperative to consider a suitable development process that reflects the engineering mind-set, with heavy emphasis on good analysis and design for quality assurance.
Transitioning IT Projects to Operations Effectively in Public Sector : A Case...ijmpict
Operational effectiveness is measured by the application availability to end-users and the extent of
convenient usage of the application to perform their business functions. This paper demonstrates how
varying project transition process can affect the operational effectiveness. This explanatory case study
uses various projects in a South Australian government agency as the candidates for evaluation. With
various applications that existed in the production environment, the end-users had varying levels of
satisfaction. This research analyses factors influencing the operational efficiency the projects in transition
from project delivery into operations. The evidence clearly demonstrates criticality of the transition
process of applications from project delivery phase to operations phase. The research analyses the
findings specific to government agencies and presents recommendations. These findings can be useful to
public sector agencies for improving availability of IT applications in operations.
Selecting the team members is one of the greatest challenges of a software development project. This challenge is heightened by the sector’s shift to global software development and distributed projects, due to the multiple teams and members involved. This study’s proposed model enhances the peer-evaluation approach, a common technique in the domain of human resources, to support software development project managers in selecting and allocating members to the optimum team for maximum harmony. The proposed model, known as PETMS, facilitates the assessment of potential team members across multiple projects by using peer evaluations of each member together with an evaluation by the project manager. The study discusses the impact of peer evaluation on the assessment of both individual team members and the whole team. The results provide clear indications about team members that can help a project manager to select and allocate them to the right place. In addition, the study reveals that there is no clear correlation between individual- and whole-team assessment. This can impact on a project significantly.
An Agile Software Development FrameworkWaqas Tariq
Agility in software projects can be attained when software development methodologies attain to external factors and provide a framework internally for keeping software development projects focused. Developer practices are the most important factor that has to cope with the challenges. Agile development assumes a project context where the customer is actively collaborating with the development team. The greatest problem agile teams face is too little involvement from the customer. For a project to be agile, the developers have to cope with this lack of collaboration. Embracing changing requirements is not enough to make agile methods cope with business and technology changes. This paper provides a conceptual framework for tailoring agile methodologies to face different challenges. The framework is comprised of three factors, namely, developer practices, customer collaboration, and predicting change
IT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERSijseajournal
The study intended to unravel critical IT project showstoppers which tend to halt IT projects temporarily or permanently, and ultimately cause them to fail, by positioning them in the systems development life cycle (SDLC) framework. Interviewing 8 IT project and program managers of the banking and telecommunications industries in Ghana individually and in a group, 19 critical showstoppers were identified spanning the whole SDLC. Generally, it was observed that for the successful completion of IT projects, the expertise and availability of project managers and team members are critical. Again, the project manager must be able to prove that the project is in line with the objectives and strategic direction of the business, is being mounted to gain competitive advantage, and has a solid business case. Thirdly, funding is key at all stages of the cycle, as well as approval for continuation at various stages.
It is impossible to separate the human factors from software engineering expertise during
software development, because software is developed by people and for people. The intangible
nature of software has made it a difficult product to successfully create, and an examination of
the many reasons for major software system failures show that the reasons for failures
eventually come down to human issues. Software developers, immersed as they are in the
technological aspect of the product, can quickly learn lessons from technological failures and
readily come up with solutions to avoid them in the future, yet they do not learn lessons from
human aspects in software engineering. Dealing with human errors is much more difficult for
developers and often this aspect is overlooked in the evaluation process as developers move on
to issues that they are more comfortable solving. A major reason for this oversight is that
software psychology (the softer side) has not developed as extensively
These days, organizations battle to get by in a worldwide rivalry. Each organization tries to locate the best rationality which is appropriate with their procedure to increase any and each favorable position among their opponents. Organizations ought to be more centered around understanding their own particular structure as far as procedures whether they are in the creation or administration division. The point and extent of this venture is to distinguish the requirements in development extend working condition. On the off chance that requirements are better comprehended at the beginning, it is trusted that better execution can be guaranteed. Distinguishing and expelling imperatives from bottleneck exercises help to decrease instabilities in development procedures and builds the straightforwardness of venture administration. This investigation was done in light of writing audit and a poll study. The information for this examination will be assembling through a point by point poll overview. The poll shape is sent to different development enterprises through email and in individual. The targets of the examination is to effectively lessen the imperatives which will diminish the superfluous wastage and loss of both cash and time due to deficient arranging.
EMPIRICAL STUDY OF THE EVOLUTION OF AGILE-DEVELOPED SOFTWARE SYSTEM IN JORDAN...ijbiss
The focus of agile in software development methods and practices. How to take effective methods in use
have received less attention. Especially in a large organization is not a little to take in agile methods to use.
This paper discusses the adoption and level of experience of the use of agile practices in three companies
in the software development company wide contacts in Jordan. The more practices that relied on largescale
flexibility to measure the progress made by the code work, that the developers efforts to the task of
estimating, to the use of coding standards, and the lack of overtime continuous, has a team to develop their
own operations, to use the limited documentation, and to have the team in one place facility. The adoption
of agile practices of the test, any test of the first unit tests and automated, and low. Some can only appear
agile practices without the adoption of a conscious, because developers find them useful. So it seems that
an emergency operation aimed at agility may also neglect the important agile practices.
Working software measures the progress. Basically, Agile method involves interleaving the specification, implementation, design and testing. Series of versions are developed with the involvement of and evaluation by the stake holders in each version. Agile methods aim at reducing the software process overheads (like documentation) and concentrate more on code rather than the design. Customer involvement, incremental delivery, freedom of developers to evolve new working methods, change management, and last but not the least simplicity is the basic essence of Agile development. Agile methodologies are well suited for small as well as medium sized projects.
http://essaysreasy.com .That's a sample paper - essay / paper on the topic "Information systems engineering" created by our writers!
Disclaimer: The paper above have been completed for actual clients. We have acclaimed personal permission from the customers to post it.
Lindorff Group is a leading outsourced receivables management company in Europe, and one of the leading on a global basis. For the past three–four years, they have increasingly adopted agile practices, especially in a large scale project converting and improving an old system written in Powerhouse to new .Net–technology.
The results from adopting agile practices have been mostly positive, however, there were challenging issues related to requirement handling and estimation that needed attention. In 2008, Lindorff joined a project with Symphonical funded by Innovation Norway. The purpose of the project was to develop software for requirements handling, estimation and knowledge management for the Symphonical platform. Symphonical is a flexible web–based collaboration platform, where users can brainstorm, plan, organize and coordinate any process.
This talk presents results from a case study detailing the challenges faced by Lindorff as they simultaneously adopted agile practices and introduced a new system for requirement handling and estimation. According to the respondents of the case study, Lindorff appears to have improved on two of the main points of concern presented in the 2007 study: requirement handling and estimation. Many users report that the introduction of agile methods and the platform Symphonical has improved the quality of important work processes. Furthermore, they report that the introduction of Symphonical has provided a framework for structured discussions regarding individual requirements, which helps maintaining the focus of IT projects. Furthermore, the flexible sharing regime where one can easily share information to external participants improves the effectiveness and efficiency of collaboration with all project contributors.
ITERATIVE AND INCREMENTAL DEVELOPMENT ANALYSIS STUDY OF VOCATIONAL CAREER INF...ijseajournal
Software development process presents various types of models with their corresponding phases required to be accordingly followed in delivery of quality products and projects. Despite the various expertise and skills of systems analysts, designers, and programmers, systems failure is inevitable when a suitable development process model is not followed. This paper focuses on the Iterative and Incremental Development (IID)model and justified its role in the analysis and design software systems. The paper adopted the qualitative research approach that justified and harnessed the relevance of IID in the context of systems analysis and design using the Vocational
Career Information System (VCIS) as a case study. The paper viewed the IID as a change-driven software development process model. The results showed some system specification, functional specification of system and design specifications that can be used in implementing the VCIS using the IID model. Thus, the paper concluded that in systems analysis and design, it is imperative to consider a suitable development process that reflects the engineering mind-set, with heavy emphasis on good analysis and design for quality assurance.
Transitioning IT Projects to Operations Effectively in Public Sector : A Case...ijmpict
Operational effectiveness is measured by the application availability to end-users and the extent of
convenient usage of the application to perform their business functions. This paper demonstrates how
varying project transition process can affect the operational effectiveness. This explanatory case study
uses various projects in a South Australian government agency as the candidates for evaluation. With
various applications that existed in the production environment, the end-users had varying levels of
satisfaction. This research analyses factors influencing the operational efficiency the projects in transition
from project delivery into operations. The evidence clearly demonstrates criticality of the transition
process of applications from project delivery phase to operations phase. The research analyses the
findings specific to government agencies and presents recommendations. These findings can be useful to
public sector agencies for improving availability of IT applications in operations.
Selecting the team members is one of the greatest challenges of a software development project. This challenge is heightened by the sector’s shift to global software development and distributed projects, due to the multiple teams and members involved. This study’s proposed model enhances the peer-evaluation approach, a common technique in the domain of human resources, to support software development project managers in selecting and allocating members to the optimum team for maximum harmony. The proposed model, known as PETMS, facilitates the assessment of potential team members across multiple projects by using peer evaluations of each member together with an evaluation by the project manager. The study discusses the impact of peer evaluation on the assessment of both individual team members and the whole team. The results provide clear indications about team members that can help a project manager to select and allocate them to the right place. In addition, the study reveals that there is no clear correlation between individual- and whole-team assessment. This can impact on a project significantly.
An Agile Software Development FrameworkWaqas Tariq
Agility in software projects can be attained when software development methodologies attain to external factors and provide a framework internally for keeping software development projects focused. Developer practices are the most important factor that has to cope with the challenges. Agile development assumes a project context where the customer is actively collaborating with the development team. The greatest problem agile teams face is too little involvement from the customer. For a project to be agile, the developers have to cope with this lack of collaboration. Embracing changing requirements is not enough to make agile methods cope with business and technology changes. This paper provides a conceptual framework for tailoring agile methodologies to face different challenges. The framework is comprised of three factors, namely, developer practices, customer collaboration, and predicting change
The Emerging Role of Data Scientists on Software Developmen.docxarnoldmeredith47041
The Emerging Role of Data Scientists
on Software Development Teams
Miryung Kim
UCLA
Los Angeles, CA, USA
[email protected]
Thomas Zimmermann Robert DeLine Andrew Begel
Microsoft Research
Redmond, WA, USA
{tzimmer, rdeline, andrew.begel}@microsoft.com
ABSTRACT
Creating and running software produces large amounts of raw data
about the development process and the customer usage, which can
be turned into actionable insight with the help of skilled data scien-
tists. Unfortunately, data scientists with the analytical and software
engineering skills to analyze these large data sets have been hard to
come by; only recently have software companies started to develop
competencies in software-oriented data analytics. To understand
this emerging role, we interviewed data scientists across several
product groups at Microsoft. In this paper, we describe their educa-
tion and training background, their missions in software engineer-
ing contexts, and the type of problems on which they work. We
identify five distinct working styles of data scientists: (1) Insight
Providers, who work with engineers to collect the data needed to
inform decisions that managers make; (2) Modeling Specialists,
who use their machine learning expertise to build predictive mod-
els; (3) Platform Builders, who create data platforms, balancing
both engineering and data analysis concerns; (4) Polymaths, who
do all data science activities themselves; and (5) Team Leaders,
who run teams of data scientists and spread best practices. We fur-
ther describe a set of strategies that they employ to increase the im-
pact and actionability of their work.
Categories and Subject Descriptors:
D.2.9 [Management]
General Terms:
Management, Measurement, Human Factors.
1. INTRODUCTION
Software teams are increasingly using data analysis to inform their
engineering and business decisions [1] and to build data solutions
that utilize data in software products [2]. The people who do col-
lection and analysis are called data scientists, a term coined by DJ
Patil and Jeff Hammerbacher in 2008 to define their jobs at
LinkedIn and Facebook [3]. The mission of a data scientist is to
transform data into insight, providing guidance for leaders to take
action [4]. One example is the use of user telemetry data to redesign
Windows Explorer (a tool for file management) for Windows 8.
Data scientists on the Windows team discovered that the top ten
most frequent commands accounted for 81.2% of all of invoked
commands, but only two of these were easily accessible from the
command bar in the user interface 8 [5]. Based on this insight, the
team redesigned the user experience to make these hidden com-
mands more prominent.
Until recently, data scientists were found mostly on software teams
whose products were data-intensive, like internet search and adver-
tising. Today, we have reached an inflection point where many.
The Emerging Role of Data Scientists on Software Developmen.docxtodd701
The Emerging Role of Data Scientists
on Software Development Teams
Miryung Kim
UCLA
Los Angeles, CA, USA
[email protected]
Thomas Zimmermann Robert DeLine Andrew Begel
Microsoft Research
Redmond, WA, USA
{tzimmer, rdeline, andrew.begel}@microsoft.com
ABSTRACT
Creating and running software produces large amounts of raw data
about the development process and the customer usage, which can
be turned into actionable insight with the help of skilled data scien-
tists. Unfortunately, data scientists with the analytical and software
engineering skills to analyze these large data sets have been hard to
come by; only recently have software companies started to develop
competencies in software-oriented data analytics. To understand
this emerging role, we interviewed data scientists across several
product groups at Microsoft. In this paper, we describe their educa-
tion and training background, their missions in software engineer-
ing contexts, and the type of problems on which they work. We
identify five distinct working styles of data scientists: (1) Insight
Providers, who work with engineers to collect the data needed to
inform decisions that managers make; (2) Modeling Specialists,
who use their machine learning expertise to build predictive mod-
els; (3) Platform Builders, who create data platforms, balancing
both engineering and data analysis concerns; (4) Polymaths, who
do all data science activities themselves; and (5) Team Leaders,
who run teams of data scientists and spread best practices. We fur-
ther describe a set of strategies that they employ to increase the im-
pact and actionability of their work.
Categories and Subject Descriptors:
D.2.9 [Management]
General Terms:
Management, Measurement, Human Factors.
1. INTRODUCTION
Software teams are increasingly using data analysis to inform their
engineering and business decisions [1] and to build data solutions
that utilize data in software products [2]. The people who do col-
lection and analysis are called data scientists, a term coined by DJ
Patil and Jeff Hammerbacher in 2008 to define their jobs at
LinkedIn and Facebook [3]. The mission of a data scientist is to
transform data into insight, providing guidance for leaders to take
action [4]. One example is the use of user telemetry data to redesign
Windows Explorer (a tool for file management) for Windows 8.
Data scientists on the Windows team discovered that the top ten
most frequent commands accounted for 81.2% of all of invoked
commands, but only two of these were easily accessible from the
command bar in the user interface 8 [5]. Based on this insight, the
team redesigned the user experience to make these hidden com-
mands more prominent.
Until recently, data scientists were found mostly on software teams
whose products were data-intensive, like internet search and adver-
tising. Today, we have reached an inflection point where many.
Towards understanding the influence of personality and team behaviors on requ...IJECEIAES
Requirements engineers play an important role in the development of software products and services. The nature of requirements engineering (RE) is multifaceted and influences the quality, success, or failure of software products. In gathering software requirements, engineers commonly work in a team, particularly when dealing with the customers or modeling the requirements, hence the team behavior may influence the RE activities. The investigation of requirements engineers’ personality and their team behavior associated with RE activities is still an open area in which research is still developing. This study aims to investigate the personality and team behavior of requirements engineers involved in RE activities using a systematic literature review approach. We included 64 primary studies that addressed the association between personality and team behavior of requirements engineers on the effectiveness of RE activities. The result shows that among personality dimensions, extraversion and conscientiousness were found to be the predominant personality traits that positively affect RE activities. Furthermore, team behavior of requirements engineers such as flexibility, collaboration, creativity, innovation, and norms were discovered as factors that influence the RE process, performance, and success. The findings of this study contribute to the body of knowledge and practice of RE by providing empirical evidence on the influence of requirements engineers’ personality and team behavior on the effectiveness of RE activities.
To document or not to document? An exploratory study on developers' motivatio...Hayim Makabee
Abstract: Technical debt represents the situation in a project where developers accept compromises in one dimension of a system in order to meet urgent demands in other dimensions. These compromises incur a “debt”, on which “interest” has to be paid to maintain the long-term health of the project. One of the elements of technical debt is documentation debt due to under-documentation of the evolving system. In this exploratory study, our goal is to examine the different aspects of developers' motivation to document code. Specifically, we aim to identify the motivating and hindering aspects of documentation as perceived by the developers. The motivating aspects of code documenting we find include improving code comprehensibility, order, and quality. The hindering aspects include developers’ perception of documenting as a tedious, difficult, and time consuming task that interrupts the coding process. These findings may serve as a basis for developing guidelines toward improving documentation practices and encouraging developers to document their code thus reducing documentation debt.
Impact of Stress on Software Engineers Knowledge Sharing and Creativity [A Pa...ijcnes
Software development involves technology as well as human efforts. Software engineering is supportive to create a quality of product by adopting the process of sharing knowledge. A lot of research was conducted on the technical side but human side of software development disregarded. Knowledge and creativity considered major factors for improving the software quality. Currently professionals working in the field of software engineering are under impressive pressure which cause stress for the Software engineers. It is highly desirable to conduct an empirical study on impact of stress on software engineers knowledge sharing & creativity. The major motivation for this study is to investigate the impact of job stress factors which can affect the software engineering knowledge sharing capabilities and creativity. The research is based on industrial assessment. For conducting this study we developed a questionnaire based on Stress Factors. Statistical analyses are performed through SPSS tool. On the basis of the results from the survey, we proposed some strategies for those factors that have high impact on software engineers and try to mitigate their affect. These results highlight stress factors and their impact on software engineers knowledge sharing and creativity, working in Pakistani software industry.
An Investigation of Critical Failure Factors In Information Technology ProjectsIOSR Journals
Rate of failed projects in information technology system project remains high in comparison with other infrastructure or high technology projects. The objective of this paper is to determine and represent a broad range of potential failure factors during the implementation phase and cause of IS/IT Project defeat/failure. Challenges exist in order to achieve the projects goal successfully and to avoid the failure. In this research study, 12 articles were studied as significant contributions to analyze developing a list of critical failure factors of IT projects
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
EMPLOYERS’ NEEDS FOR COMPUTER SCIENCE, INFORMATION TECHNOLOGY AND SOFTWARE EN...ijcseit
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
EMPLOYERS’ NEEDS FOR COMPUTER SCIENCE, INFORMATION TECHNOLOGY AND SOFTWARE EN...ijcseit
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
EMPLOYERS’ NEEDS FOR COMPUTER SCIENCE, INFORMATION TECHNOLOGY AND SOFTWARE EN...ijcseit
Graduates of computer science programs often lack skills that employers desire among software
developers. These include, for example, weaknesses in the areas of collaboration, communication, and
software testing. Further research can help to refine this list by providing insight into additional skills that
are of rising or regional importance. This paper therefore presents a study aimed at uncovering desirable
technical and soft skills for graduates of computer science in the Pacific Northwest region of the United
States. Interviews of 11 employers, including both managers and recruiters, highlighted the prominent
importance of skills related to web development, relational databases, and testing. Additionally, it
spotlighted not only widely-recognized soft skills such as those related to collaboration and
communication, but additionally on skills tied to personal attributes such as innovating, coping with
ambiguity and learning quickly. The results provide insights for what skills and personal attributes to
include in a future survey of employers aimed at quantifying the importance of skills on this list.
Similar to what makes a great software engineer? (20)
Globus Compute wth IRI Workflows - GlobusWorld 2024Globus
As part of the DOE Integrated Research Infrastructure (IRI) program, NERSC at Lawrence Berkeley National Lab and ALCF at Argonne National Lab are working closely with General Atomics on accelerating the computing requirements of the DIII-D experiment. As part of the work the team is investigating ways to speedup the time to solution for many different parts of the DIII-D workflow including how they run jobs on HPC systems. One of these routes is looking at Globus Compute as a way to replace the current method for managing tasks and we describe a brief proof of concept showing how Globus Compute could help to schedule jobs and be a tool to connect compute at different facilities.
Custom Healthcare Software for Managing Chronic Conditions and Remote Patient...Mind IT Systems
Healthcare providers often struggle with the complexities of chronic conditions and remote patient monitoring, as each patient requires personalized care and ongoing monitoring. Off-the-shelf solutions may not meet these diverse needs, leading to inefficiencies and gaps in care. It’s here, custom healthcare software offers a tailored solution, ensuring improved care and effectiveness.
SOCRadar Research Team: Latest Activities of IntelBrokerSOCRadar
The European Union Agency for Law Enforcement Cooperation (Europol) has suffered an alleged data breach after a notorious threat actor claimed to have exfiltrated data from its systems. Infamous data leaker IntelBroker posted on the even more infamous BreachForums hacking forum, saying that Europol suffered a data breach this month.
The alleged breach affected Europol agencies CCSE, EC3, Europol Platform for Experts, Law Enforcement Forum, and SIRIUS. Infiltration of these entities can disrupt ongoing investigations and compromise sensitive intelligence shared among international law enforcement agencies.
However, this is neither the first nor the last activity of IntekBroker. We have compiled for you what happened in the last few days. To track such hacker activities on dark web sources like hacker forums, private Telegram channels, and other hidden platforms where cyber threats often originate, you can check SOCRadar’s Dark Web News.
Stay Informed on Threat Actors’ Activity on the Dark Web with SOCRadar!
Enhancing Project Management Efficiency_ Leveraging AI Tools like ChatGPT.pdfJay Das
With the advent of artificial intelligence or AI tools, project management processes are undergoing a transformative shift. By using tools like ChatGPT, and Bard organizations can empower their leaders and managers to plan, execute, and monitor projects more effectively.
Large Language Models and the End of ProgrammingMatt Welsh
Talk by Matt Welsh at Craft Conference 2024 on the impact that Large Language Models will have on the future of software development. In this talk, I discuss the ways in which LLMs will impact the software industry, from replacing human software developers with AI, to replacing conventional software with models that perform reasoning, computation, and problem-solving.
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...Anthony Dahanne
Les Buildpacks existent depuis plus de 10 ans ! D’abord, ils étaient utilisés pour détecter et construire une application avant de la déployer sur certains PaaS. Ensuite, nous avons pu créer des images Docker (OCI) avec leur dernière génération, les Cloud Native Buildpacks (CNCF en incubation). Sont-ils une bonne alternative au Dockerfile ? Que sont les buildpacks Paketo ? Quelles communautés les soutiennent et comment ?
Venez le découvrir lors de cette session ignite
top nidhi software solution freedownloadvrstrong314
This presentation emphasizes the importance of data security and legal compliance for Nidhi companies in India. It highlights how online Nidhi software solutions, like Vector Nidhi Software, offer advanced features tailored to these needs. Key aspects include encryption, access controls, and audit trails to ensure data security. The software complies with regulatory guidelines from the MCA and RBI and adheres to Nidhi Rules, 2014. With customizable, user-friendly interfaces and real-time features, these Nidhi software solutions enhance efficiency, support growth, and provide exceptional member services. The presentation concludes with contact information for further inquiries.
May Marketo Masterclass, London MUG May 22 2024.pdfAdele Miller
Can't make Adobe Summit in Vegas? No sweat because the EMEA Marketo Engage Champions are coming to London to share their Summit sessions, insights and more!
This is a MUG with a twist you don't want to miss.
Innovating Inference - Remote Triggering of Large Language Models on HPC Clus...Globus
Large Language Models (LLMs) are currently the center of attention in the tech world, particularly for their potential to advance research. In this presentation, we'll explore a straightforward and effective method for quickly initiating inference runs on supercomputers using the vLLM tool with Globus Compute, specifically on the Polaris system at ALCF. We'll begin by briefly discussing the popularity and applications of LLMs in various fields. Following this, we will introduce the vLLM tool, and explain how it integrates with Globus Compute to efficiently manage LLM operations on Polaris. Attendees will learn the practical aspects of setting up and remotely triggering LLMs from local machines, focusing on ease of use and efficiency. This talk is ideal for researchers and practitioners looking to leverage the power of LLMs in their work, offering a clear guide to harnessing supercomputing resources for quick and effective LLM inference.
Developing Distributed High-performance Computing Capabilities of an Open Sci...Globus
COVID-19 had an unprecedented impact on scientific collaboration. The pandemic and its broad response from the scientific community has forged new relationships among public health practitioners, mathematical modelers, and scientific computing specialists, while revealing critical gaps in exploiting advanced computing systems to support urgent decision making. Informed by our team’s work in applying high-performance computing in support of public health decision makers during the COVID-19 pandemic, we present how Globus technologies are enabling the development of an open science platform for robust epidemic analysis, with the goal of collaborative, secure, distributed, on-demand, and fast time-to-solution analyses to support public health.
Experience our free, in-depth three-part Tendenci Platform Corporate Membership Management workshop series! In Session 1 on May 14th, 2024, we began with an Introduction and Setup, mastering the configuration of your Corporate Membership Module settings to establish membership types, applications, and more. Then, on May 16th, 2024, in Session 2, we focused on binding individual members to a Corporate Membership and Corporate Reps, teaching you how to add individual members and assign Corporate Representatives to manage dues, renewals, and associated members. Finally, on May 28th, 2024, in Session 3, we covered questions and concerns, addressing any queries or issues you may have.
For more Tendenci AMS events, check out www.tendenci.com/events
Enhancing Research Orchestration Capabilities at ORNL.pdfGlobus
Cross-facility research orchestration comes with ever-changing constraints regarding the availability and suitability of various compute and data resources. In short, a flexible data and processing fabric is needed to enable the dynamic redirection of data and compute tasks throughout the lifecycle of an experiment. In this talk, we illustrate how we easily leveraged Globus services to instrument the ACE research testbed at the Oak Ridge Leadership Computing Facility with flexible data and task orchestration capabilities.
We describe the deployment and use of Globus Compute for remote computation. This content is aimed at researchers who wish to compute on remote resources using a unified programming interface, as well as system administrators who will deploy and operate Globus Compute services on their research computing infrastructure.
How Recreation Management Software Can Streamline Your Operations.pptxwottaspaceseo
Recreation management software streamlines operations by automating key tasks such as scheduling, registration, and payment processing, reducing manual workload and errors. It provides centralized management of facilities, classes, and events, ensuring efficient resource allocation and facility usage. The software offers user-friendly online portals for easy access to bookings and program information, enhancing customer experience. Real-time reporting and data analytics deliver insights into attendance and preferences, aiding in strategic decision-making. Additionally, effective communication tools keep participants and staff informed with timely updates. Overall, recreation management software enhances efficiency, improves service delivery, and boosts customer satisfaction.
Enterprise Resource Planning System includes various modules that reduce any business's workload. Additionally, it organizes the workflows, which drives towards enhancing productivity. Here are a detailed explanation of the ERP modules. Going through the points will help you understand how the software is changing the work dynamics.
To know more details here: https://blogs.nyggs.com/nyggs/enterprise-resource-planning-erp-system-modules/
How to Position Your Globus Data Portal for Success Ten Good PracticesGlobus
Science gateways allow science and engineering communities to access shared data, software, computing services, and instruments. Science gateways have gained a lot of traction in the last twenty years, as evidenced by projects such as the Science Gateways Community Institute (SGCI) and the Center of Excellence on Science Gateways (SGX3) in the US, The Australian Research Data Commons (ARDC) and its platforms in Australia, and the projects around Virtual Research Environments in Europe. A few mature frameworks have evolved with their different strengths and foci and have been taken up by a larger community such as the Globus Data Portal, Hubzero, Tapis, and Galaxy. However, even when gateways are built on successful frameworks, they continue to face the challenges of ongoing maintenance costs and how to meet the ever-expanding needs of the community they serve with enhanced features. It is not uncommon that gateways with compelling use cases are nonetheless unable to get past the prototype phase and become a full production service, or if they do, they don't survive more than a couple of years. While there is no guaranteed pathway to success, it seems likely that for any gateway there is a need for a strong community and/or solid funding streams to create and sustain its success. With over twenty years of examples to draw from, this presentation goes into detail for ten factors common to successful and enduring gateways that effectively serve as best practices for any new or developing gateway.
Climate Science Flows: Enabling Petabyte-Scale Climate Analysis with the Eart...Globus
The Earth System Grid Federation (ESGF) is a global network of data servers that archives and distributes the planet’s largest collection of Earth system model output for thousands of climate and environmental scientists worldwide. Many of these petabyte-scale data archives are located in proximity to large high-performance computing (HPC) or cloud computing resources, but the primary workflow for data users consists of transferring data, and applying computations on a different system. As a part of the ESGF 2.0 US project (funded by the United States Department of Energy Office of Science), we developed pre-defined data workflows, which can be run on-demand, capable of applying many data reduction and data analysis to the large ESGF data archives, transferring only the resultant analysis (ex. visualizations, smaller data files). In this talk, we will showcase a few of these workflows, highlighting how Globus Flows can be used for petabyte-scale climate analysis.
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...informapgpstrackings
Keep tabs on your field staff effortlessly with Informap Technology Centre LLC. Real-time tracking, task assignment, and smart features for efficient management. Request a live demo today!
For more details, visit us : https://informapuae.com/field-staff-tracking/
1. What Makes A Great Software Engineer?
Paul Luo Li*+
, Andrew J. Ko*, Jiamin Zhu+
Microsoft+
Seattle, WA
{pal,jiaminz}@microsoft.com
The Information School*
University of Washington
ajko@uw.edu
Abstract—Good software engineers are essential to the creation
of good software. However, most of what we know about software-
engineering expertise are vague stereotypes, such as ‘excellent
communicators’ and ‘great teammates’. The lack of specificity in
our understanding hinders researchers from reasoning about
them, employers from identifying them, and young engineers from
becoming them. Our understanding also lacks breadth: what are
all the distinguishing attributes of great engineers (technical
expertise and beyond)? We took a first step in addressing these
gaps by interviewing 59 experienced engineers across 13 divisions
at Microsoft, uncovering 53 attributes of great engineers. We
explain the attributes and examine how the most salient of these
impact projects and teams. We discuss implications of this
knowledge on research and the hiring and training of engineers.
Index Terms—Software engineers, expertise, teamwork
I. INTRODUCTION
Software engineering research has considered a vast number
of factors that affect project outcomes, from process and tools,
to programming languages and requirement elicitation. We
rarely give consideration, however, to one of the most
fundamental components of software engineering: the engineers
themselves. Specifically, what makes a software engineer great?
This basic question is at the foundation of nearly every part of
our world’s rapidly growing software ecosystem: employers
want to hire and retain great engineers, universities want to train
great engineers, and young engineers want to become great. And
yet our understanding of what characteristics define software
engineering expertise still lacks specificity, breadth, and rigor.
The research we do have on this subject is directionally
sound, but often too indirect or abstract to form a foundational
understanding of software-engineering expertise. For example,
some research has considered experiences of new hires [1][2],
finding that engineers need to contribute value to the team, not
become blocked (i.e. have self-efficacy and be persistent), and
effectively navigate large organizations. Other research hints at
important attributes, but only indirectly. For example, research
on teaching novices [3] and programmer productivity [4][5]
indicate experts are generally more productive: producing
solutions faster, producing more in the same amount of time,
and/or having fewer bugs.
Software engineering education research is another source of
information about software engineering expertise, but it is
prescriptive rather than descriptive. For example, several studies
suggest what ought to be in the ACM Computing Curricula
[6][7][8][9], arguing that engineers need knowledge of technical
areas and techniques such as programming fundamentals,
verification/validation, and project management.
In this study, we sought to remedy the lack of specificity,
breadth, and rigor in prior work by investigating the following
about software engineers:
• What do expert software engineers think are attributes of
great software engineers?
• Why are these attributes important for the engineering of
software?
• How do these attributes relate to each other?
To answer these questions, we performed 59 semi-structured
interviews, spanning 13 Microsoft divisions, including several
interviews with architect-level engineers with over 25 years of
experience. The contribution of this effort is a thorough, specific,
and contextual understanding of software engineering expertise,
as viewed by expert software engineers.
In the rest of this paper, we detail our current understanding
of software engineering expertise. We then discuss our interview
and analysis methodology, the attributes we discovered, and the
implications of this knowledge for software engineering
research, practice, and training.
II. RELATED WORK
Much of our knowledge of software engineering expertise
come from studying new engineers rather than experienced ones.
For example, the closest work to ours is Hewner and Guzdial’s
investigation of what employers in a small game company look
for in new graduates [2]. The authors interviewed and surveyed
over 30 engineers, managers, and artists about qualifications for
recent graduates. The authors identified programming skills as
well as people skills, like the ‘ability to work with others and
check your ego at the door’. In addition to biases for the gaming
industry, the authors also suggested differences in expectations
between new and senior hires. Begel and Simon’s 2008 ICER
paper performed a similar investigation [1], following 8 new
hires at Microsoft for 4 weeks and examining their daily tasks.
The authors found that novices need to identify ‘tasks that have
an impact’, to be ‘persistent’ (avoid lack of self-efficacy), and to
collaborate effectively in a ‘large-scale software team setting’.
However, it was unclear whether experienced engineers had
similar issues.
Some works are prescriptive, offering recommendations, but
often providing few insights into why topics are (or are not)
important. For example, Lethbridge [10] surveyed 168 software
professionals about the relevance of computer science education
topics from the ACM Computing Curricula [6]. A notable
exception is Kelley’s work examining star performers, including
software engineers at HP and Bell Labs [11]. The authors
prescribed nine working strategies and described how they lead
to high productivity—blazing trails, knowing who knows,
2. proactive self-management, getting the big picture, the right kind
of followership, teamwork as joint ownership of a project, small-
I leadership, street smarts, and show and tell.
Other works have considered related occupations such as
“Information Technology” [8] and “Information Systems” [12].
Many of the needs, like ‘supporting existing portfolio of
applications’ and ‘analyze business problems and IS solutions’
were directed towards selecting software rather than creating it.
Some insights into software engineering expertise have
come from luminaries. At OOPSLA 2003 [13], Brechner—a
director of development training at Microsoft—discussed the
need for design analysis, embracing diversity (e.g. other
nationalities), multidisciplinary project teaming, large-scale
development, and quality code. Dijkstra, in his Turing Award
speech [14], argued that good developers create obvious and
elegant solutions, constructed with provable correctness. These
attributes are likely important, but the luminaries were probably
not aiming to exhaustively or rigorously identify key attributes.
Popular press and best-practice guides have also considered
the topic. In a New York Times’ interview [15], Bock—
Google’s vice president of people operations—indicated that a
software engineer’s ability to learn on the job was critical, also
claiming that human judgment, inspiration, and creativity were
more important than technical knowledge. Similarly, McConnell
[16] argued that effective developers, in addition to technical
skills, had various personality traits like being humble about
their intelligence, curiosity, and intellectual honesty.
Comparisons of novices and experts also reveal insight into
software engineering expertise, showing that experts are more
productive, systematic, and well-prepared [3][17][18]. Sackman
et al., in one of the first comparisons of developer productivity
in 1968 [5], found that completion times of programming and
debugging tasks can vary as much as 28:1 between the best and
worst engineers. Researchers also suggest qualitative and
environmental differences. Robillard et al. [19] found that
effective developers were more methodical and better at
recognizing relevant information. Ericsson et al. [20]—origin of
the meme that 10,000 hours of deliberate practice is needed to
achieve expertise—found that attaining expertise required time,
materials, teachers, and facilities.
Research into various aspects of teamwork suggests other
important attributes. Simon’s research into effective
organizations [21] argued that setting, communicating, and
alignment of goals within teams are important. Gobeli et al. [22]
found that effective conflict management (e.g. confronting and
give and take) are important for successful projects. Research on
collaborations [23][24][25][26][27][28] suggests that expert
software engineers have knowledge of code ownership, the
technical domain, and argumentation skills.
While related research is extensive, few works directly
address software engineering expertise. Those that do, focus on
a narrow subset of factors. In our work, we give greater breadth,
depth, and rigor to our understanding of software engineering
expertise than the current literature offers.
III. METHOD
Ideally, an empirical study of software engineering expertise
would sample a wide-range of software companies, software
products, and company cultures. As an initial effort, we tried to
approximate the ideal by interviewing experienced engineers at
Microsoft, a large company with a diverse set of software
products and engineers. We chose face-to-face semi-structured
interviews to identify an exhaustive list of attributes with
detailed and contextualized understanding of their meaning and
importance.
A key decision in our method was determining whose
subjective opinions of software engineering expertise could be
considered credible. Licensure and accreditation of engineers is
still uncommon. The ACM's definition of software engineers as
'people who produce software for earnest use’ [6] is vague. We
therefore used the approach utilized by researchers of human
expertise [20], basing our definition of expertise on people
having achieved some degree of recognition as software
engineering experts. We selected engineers at or above the
Software Development Engineer Level 2 (SDEII) title. These
engineers were confirmed as experts by other engineers via the
hiring or promotion processes.
Based on prior work, we aimed to obtain a stratified random
sample of engineers across two important dimensions: product
type (10 major divisions at Microsoft plus one for all others
including Skype, Data Center Ops, and Distribution) and
experience level (‘experienced’—titles at or above SDEII—and
‘very experienced’—titles at or above Senior Dev Manager—
typically with 15+ years of experience). We used the corporate
address book, which the 1st
author had access to as a full time
Microsoft employee. We randomly sampled engineers in the 22
strata in a round-robin fashion with 3 employees each round,
aiming for at least 2 informants in each stratum. Of the 152
engineers we contacted, we interviewed 59 (39%), see Table 1.
The interviews were semi-structured and about 1 hour in
duration. We started by describing our study, explaining how we
located the interviewee, asking permission to record the
interview, informing them that all personally identifiable
TABLE 1. STRATIFIED RANDOM SAMPLE OF EXPERIENCED ENGINEERS AT MICROSOFT
Experience Level Product Type
Ad
Platform
Bing
Corp
Dev
Dynamics Office Phone
Server &
Tools
Windows
Windows
Services
Xbox Other Totals
Experienced titles:
SDE II, Senior SDE, Senior Dev Lead
2 2 2 2 2 3 3 6 3 2 2 29
Very Experienced titles:
Architect, Technical Fellow,
Partner Dev Manager, Partner Dev
Lead, Principal Dev Lead, Senior
Dev Manager, or Principal SDE
3 3 3 2 3 2 2 5 2 3 2 30
Totals 5 5 5 4 5 5 5 11 5 5 4 59
3. information will be removed, and detailing their rights to refuse
to answer any question and to have their responses removed
later. We began the interview by asking: “I want to start by
learning a bit more about you. What software products, at
Microsoft and elsewhere, have you worked on?” This helped us
to establish rapport and facilitated informants’ reflections; this
prior history was later removed during transcriptions to preserve
anonymity. We then asked: “Think back to someone you've
worked with that you thought was a great software engineer.
What were some attributes that made the person 'great' in your
mind?” We asked follow-up and clarification questions for
attributes that we thought were interesting (e.g. novel, vague, or
counter to prior informants).
In the second part of the interview, we asked about attributes
that either lacked clarity or (we thought) might vary in
interpretation. As we learned more about the attributes from
interviewees, we updated the set of attributes we inquired about
(once every ~10 interviews). For time considerations, we limited
our discussions to 5 attributes of interest. We closed the
interview by restating the purpose of the research and asking
interviewees whether they had anything else to add.
To analyze the more than 60 hours of interviews and 388,000
words of transcripts, we used a grounded theory approach [29].
We began with open coding, identifying and assessing all
excerpts that discussed attributes of great software engineers.
Once we developed our initial attributes, descriptions, and
groupings, we made a selective coding pass through our data—
consolidating the attribute set. To validate our interpretations,
we then solicited the help of a Senior Software Development
Engineer (3rd
author) to analyze roughly 1/3 of the interviews,
developing her own attributes, definitions, and groupings, and
then consolidating with the initial set. We made a final pass
through all transcripts to produce the final set of attributes.
IV. FINDINGS
Our analysis identified a diverse set of 53 attributes of great
software engineers. At a high level, our informants described
great engineers as people who are passionate about their jobs and
are continuously improving; who develop and maintain practical
decision-making models based on theory and experience; who
grow their capability to produce software that are elegant,
creative, and anticipate needs; who evaluate tradeoffs at multiple
levels of abstraction, from low-level technical details to big-
picture strategies; and whom teammates trust and enjoy working
with.
To give readers a sense of how the attributes interconnect,
we present a model of the 53 attributes in Fig 1. We organize the
attributes into internal attributes of the engineer’s personality
and ability to make effective decisions, as well as external
attributes of the impact that great engineers have on people and
product. Making effective decisions involved recognizing
situations as well as knowing alternative courses of action, likely
outcomes, and values of outcomes. The external attributes
focused on great engineers applying their emotional intelligence
and decision-making models to their software, their teammates,
and the potentially millions of users and stakeholders they serve
via their software engineering efforts.
Many of the attributes are applicable to many professions,
and some, to simply being a good person. Our objective was to
identify, among all possible attributes, the set that expert
software engineers viewed as important for the engineering of
software. More importantly, we aimed to provide a
contextualized understanding of why these attributes are
important in real-world practice.
In the rest of this section, we provide a description of each
attribute and quotes from informants (including their title and
division when this information would not reveal their identity)
that capture the sentiment in interviews. Due to space
limitations, we focus detailed descriptions on attributes that we
felt—based on prior work—were particularly interesting.
A. Personal Characteristics
Informants mentioned 18 attributes of engineers’
personalities (see Table 2). With attributes like passionate and
curious, these concerned who great engineers were as people.
For many attributes, informants felt that the attributes were
intrinsic to the engineer—formed through their upbringing—
and were difficult (if not impossible) to change.
Fig. 1. Model of attributes of great software engineers, with attributes we discuss in detailed in bold.
4. 1) Improving
Informants described great engineers as improving: not
satisfied with the status quo and constantly looking to improve
themselves, their product, and/or their surroundings. Informants
believed that engineers did not start their careers being great, but
that young engineers needed to learn and improve. Informants
also felt that because the software field was rapidly changing and
evolving, unless engineers kept learning, they would not become
and would not continue to be great software engineers. This
notion of running up an infinite escalator was prevalent among
informants:
“Computer technology, compared to other sciences or technology, it's pretty
young. Every year there's some new technology, new ideas. If you are only
satisfied with things you already learned, then you probably find out in a few
years, you're out of date… good software engineer [sic], he keep investigate,
investment. [sic]” -SDE2, Corp Dev
2) Passionate
Informants described great engineers as passionate:
intrinsically interested in the area they are working in, and not
just for extrinsic rewards such as money. Informants felt that
software engineering required a tight fit between a person's
passion and the project to achieve high quality:
“I think that there are people who are great software engineers who are in the
wrong place and aren't motivated and they end up not performing well.” -
Principal Dev Lead, Dynamics
There was also a sentiment that no matter the subject matter,
there will be someone with a natural affinity towards it:
“I found that there's always a person who's passionate about every type of
thing, you just have to find the right people… I ended up in the wrong job for
six months. It was painful. People around me, they loved their work” -
Principal Dev Lead, Phone
3) Open-minded
Informants described great engineers as open-minded:
willing to judiciously let new information change how they
think, not taking the current understanding as gospel. Informants
felt that outcomes in software engineering (e.g. user reactions
and commercial success) were difficult to predict:
“You should be open… what you think need not be the right thing tomorrow…
like the Facebook explosion, when Myspace was already there, but it
exploded… no one knew that Facebook would explode when it started”. -
Senior SDE, Windows Services
TABLE 2. PERSONAL CHARACTERISTICS OF GREAT SOFTWARE ENGINEERS. ATTRIBUTES DISCUSSED IN DETAIL ARE IN BOLD.
Attribute and description Excerpt that capture interviewees’ sentiment
Improving—not satisfied with the status quo: constantly looking
to improve themselves, their product, and/or their surroundings.
“…Always looking to do something better, always looking for the next thing, studying
about the newer thing… to do things better.” -Senior Dev Lead, Xbox
Passionate—intrinsically interested in the area they are working
in (i.e. not just in it for extrinsic rewards like a pay check).
“You can't be a great engineer and not enjoy what you're doing… 9 to 5 wouldn't make
you a great engineer…not just to get a paycheck.” -Principal SDE, Xbox
Open-minded—willing to judiciously let new information change
how they think.
“The problem is... not being willing to take the input of others…not invented here, that’s
a huge problem.”-Principal Dev Lead, Office
Data-driven—taking and evaluating measurements of their
actions and of the software, often relative to expectations.
“The difference between fact and hypothesis… How can I prove that? A new fact might
show up, that this proves what I thought was my theory.” -Principal Dev Lead, Xbox
Systematic—taking actions in logical and ordered steps “…Have to be patient and not rush to the solution... go through a mental gymnastics in
order to get to a solution.” -Principal SDE Lead, Windows
Productive—achieving the same results as others faster, or taking the
same amount of time as others but doing more.
“He codes quickly and fast… Just write the code and figure out how to get it working.” -
Principal Dev Manager, Bing
Perseverant—not discouraged by setbacks and failures. “I will try to find out a solution. Those people always succeed …There is always a way.” -
Senior Dev Lead, Dynamics
Hardworking—working more than is expected to finish deliverables
and/or to accomplish their improvement goals.
“Sometimes… that’s just arduous. You really just need to grind through” -SDE2, Server &
Tools
Curious—wanting to know how and why things happen (i.e. how the
code and the conditions produce a software behavior or customer
reaction).
“I was always asking why. Why does that thing work? Why does it do this? What is it? For
me, I kind of had to have a need to know what made something tick and it's that
curiosity…” -Technical Fellow, division removed to preserve anonymity
Risk-taking—willing to go into high-value areas even though they
may not have knowledge or expertise (e.g. new technologies).
“They're willing to take on the challenge. So that's the most important one.” -Senior Dev
Lead, Bing
Adaptable—adapting to changes in their environment, including
changes in what they do (e.g. the software product) and how they do
it (e.g. people, processes, and tools).
“Things are going to change, what are you going to do about that?… move forward…
adapt to work with what you have to work with?”-SDE2, Service Engineering
Self-reliant—getting things done independently (i.e. not always going
to their manager for help); removing roadblocks by leveraging their
abilities and resources (e.g. asking experts for help).
“Rather than looking around for somebody to solve it for them... try to figure out how they
can do this on their own… get yourself unblocked attitude works really well.” -Principal
SDE, Windows
Self-aware—continuously assessing one’s situation and taking
corrective actions when necessary.
“A little bit of an intuition… being able to recognize this ain't working, I better start over.”
-Principal Dev Lead, Xbox
Aligned—acting for the good of the product and the organization, not
for one’s own self-interest.
“A mismatch of value… their number one goal is really to learn… you are paid because we
are a business.”-Principal Dev Manager, Windows Services
Executing—knowing when to execute; no analysis paralysis “They should not get into analysis paralysis… most optimal solution for the problem on
hand, not the most accurate solution.” -SDE2, Phone
Prideful—taking pride in oneself and ones’ product; letting their
output be a reflection of their skills and trying their best to deliver.
“Really being able to demonstrate something that you've done, that you're really proud of
… it's quality work.”-Principal Dev Lead, Xbox
Creating—wanting to bring ideas and thoughts into reality (e.g. a
software product or a feature).
“They feel more accomplished at the end of the day if they’ve actually built something…
designed something, maybe they wrote some code.” -Senior SDE, Windows
Focused—allocating and prioritizing their time for the most impactful
work.
“In an environment like Microsoft where there’s a lot of meeting and interruptions… get
focus and when to get their focus.” -Principal Dev Lead, Xbox
5. Informants also felt that because software products were
large, complex, and constantly changing; it was rare for anyone
to have a complete understanding. Therefore, even great
engineers needed to be open to changing their understanding:
“No matter how much you know, the software industry is so large… there’s so
many other areas… If that person has something to say that hadn’t occurred
to me, I’ll stop everything and say, ok, explain this. What did you see, that I
didn’t see?” -Senior SDE, Office
4) Data-driven
Several informants described great engineers as data-driven:
taking and evaluating measurements of their actions and of the
product, creating behavioral feedback loops for optimizing
software and processes. Informants believed that decisions,
when possible, should be made using data, not intuition or
arguments. Many viewed this approach as a way to avoid
confirmation bias, but lamented that it was no panacea:
“One thing that surprises me… even though we are driven by data, at least we
try to believe we are… Some data gets shown to us. We figure out some ways
to ignore it. So, maybe, maybe everybody thinks that they’re data driven, but
I’ve seen people come up with excuses for why the data doesn’t apply to them.
I’ve seen that a million times.” -Senior SDE, Office
B. Decision Making
Informants mentioned 9 attributes of engineers’ ability to
decide (see Table 3): synthesizing the current context, decision
alternatives, probabilistic outcomes, and values of outcomes.
Informants felt strongly that having book knowledge was not
sufficient; great engineers understood how decisions play-out in
complicated real-world conditions. Great engineers not only
knew what should happen, but also what can and likely will
happen.
To make effective decisions, our informants discussed
engineers needing knowledge about context along several
dimensions—technical domain, customers and business, tools
and building materials, and engineering practices—as
foundational to engineering decisions. We detail one area of
knowledge, people and organizations, because it had insights
into interpersonal dynamics not often discussed in the literature.
We also discuss engineers updating their mental models,
seeing the forest and the trees, and handling complexity.
Informants’ insights into these attributes revealed that great
engineers have complex and multi-faceted decision-making
models that were continuously being updated. This reflected the
complex decisions that great engineers often had to make.
1) Knowledgeable about people and the organization
Informants described great engineers as knowledgeable
about people and the organization. This included being informed
about their coworkers’ responsibilities, knowledge, and
tendencies. For example, knowing ownership enabled great
engineers to determine key stakeholders for decisions and to
communicate with the right people to align their work. This
alignment commonly meant their management chain, but
informants also discussed aligning with key partner teams (e.g.
other parts of a product offering):
“Make sure that you are aware of that big picture, you know where you fit in
and how you interact with everyone else to optimize what you are doing.” -
Principal Dev Lead, Ad Platform
Knowing who had expertise enabled great engineers to find
the right people for help—often domain experts—and for great
engineers in leadership positions, to take corrective actions to
address knowledge gaps (e.g. assigning a more senior person):
“[This great engineer] would go through his organization and looked very
carefully at the tasks that were being assigned and whether people had the
right level of training and understanding and if they didn’t, who their
supervisor and whether that person did and would demand code reviews...”-
Software Architect (division removed to preserve anonymity)
TABLE 3. DECISION MAKING OF GREAT SOFTWARE ENGINEERS. ATTRIBUTES DISCUSSED IN DETAIL ARE IN BOLD.
Attribute and description Excerpt that capture interviewees’ sentiment
Knowledgeable about people and the organization—informed
about the people around them: their responsibilities (i.e.
organizational structure), their knowledge, and their
tendencies
“Companies like Microsoft, there's literally people here who have created a world, the
technological world that we live in today. They’re stars in that regard… tap into this
wealth of knowledge that Microsoft brings to the table, the talent pool that’s here.” -SDE2,
Xbox
Sees the forest and the trees—considering situations at
multiple levels, including technical details, industry trends,
company vision, and customer/business needs
“…Both a very, very narrow extremely technical prospective on his code, but also know
where it fits in with the bigger picture, and to be aware of how it affects even our major
external customers, and the company vision.” -Principal SDE, Windows
Updates their mental models—keeping up to-to-date their
mental models through evaluating changes in their context
“Unlearning… two thirds or three quarters of what you know is still valuable, quarter to a
third is the wrong thing in this world and so the trick is to figure out which is which really
quickly.” -Technical Fellow, division removed to preserve anonymity
Handles complexity—able to grasp and reason about complex
and intertwining ideas
“Frighteningly intelligent and smart, and they just walk around with this picture in their
head all the time of how everything fits together.” -Principal SDE, Windows
Knowledgeable about their technical domain—thoroughly
conversant about their software product, including knowledge
about the domain and competitors
“You should have a very good understanding of the entire system as well as all of the moving
parts… the architects behind big systems, complex systems, and know it, all the gotchas, in
and out.”-Senior SDE, Windows Services
Knowledgeable about customers and business—conversant about
the role their software product plays in the lives of their customer
and the business proposition that entails
“Really understanding the point like who is the customer, why are we doing this.” -Principal
Dev Lead, Xbox
Knowledgeable about tools and building materials—versed in
strengths and limitations of the tools and building materials used to
construct their software product
“The fundamentals, you've got to learn your ... data structure, algorithm stuff inside out…
because everything else is building on them.” -Partner Dev Manager, Corp Dev
Knowledgeable about engineering processes—skilled in best
practices for building the product: their purpose, how to do them
effectively, and their cost in time and effort
“Having good practices around, how you do the code reviews and check ins and having unit
tests that enforces things don’t break and that kind of thing it is way, way more important
than the actual having a beautiful architecture.” -Principal Dev Lead , Windows Services
Models states and outcomes—building mental models linking the
current state, alternative actions, probabilistic outcomes, and value
of outcomes
“I think that mostly just comes from experience… learning where the hard parts of the
problems are probably lurking and what trouble they might cause you or something like
that… having a good pattern of recognition” -Principal Dev Lead, Corp Dev
6. Knowing people’s tendencies enabled great engineers to
adapt their engagement techniques to obtain desired outcomes:
“You have to understand people so that you can influence or impact them... You
have to do that both down and up and out.” -Principal Dev Lead, Phone
2) Sees the Forest and the Trees
Informants described great engineers as seeing the forest and
the trees, considering situations at multiple levels of abstraction,
including technical details, industry trends, company vision, and
customer/business needs. Informants indicated that mental
models could exist at various levels and that great engineers
reasoned at all levels quickly and accurately:
“What differentiated [this great engineer] from other people in management
positions… capability to zoom into the details, and he was not just a high level
guy, …know the reality of the stack or the reality of the software…” -Senior
Dev Lead, Ad Platform
Informants felt that this ability enabled great engineers to
make globally optimal decisions, avoiding local optimizations:
“The challenge is having the ability to look at things from many different
perspectives, at many different levels of abstraction or detail. Then, being able
to choose how to lay things out… make a set of choices.” -Technical Fellow
(division removed to preserve anonymity)
3) Update Their Mental Models
Informants described great engineers as continuously
updating their mental models at all levels of abstraction—
ranging from technical details to industry trends—by explicitly
evaluating changes in their context. Related to being open-
minded, this attribute concerned the process of updating mental
models, sometimes discarding existing models for new ones:
“You can always follow patterns too much... It's worked in the past, but
conditions have changed. You always need to look and take a little bit of risk
with each one of your tasks. If you're not then you're not really going to find
out what's possible.” -Principal Dev Lead, Office
Important contextual changes discussed by informants were
commonly shifts in long-held understandings in software.
Informants felt that these foundational shifts and their
implications were critical for great engineers to understand and
adapt to:
“Sometimes what used to be a second or third order effect comes to dominate.
So way back in the day, if you wanted to performance optimize something you
counted instructions. Processors got faster and faster, but memory references
didn't. There became a day when it made more sense to count memory
references than it did to count instructions. Unless you're conscious of when
those things will intersect, you'll be on the wrong side of history and be
frustrated.” -Technical Fellow (division removed to preserve anonymity)
4) Handling Complexity
Many informants described great engineers as handling
complexity with ease, grasping and reasoning about complex
and intertwining ideas with agility. Informants felt that some
software problems were inherently complex. This might have
been especially salient at Microsoft, where products commonly
build on top of multiple layers of technologies and interact with
many other components. Building an accurate mental model of
dependencies and connections was seen as critical:
“To solve the problem, [great engineers] have to have the ability to connect
things… You are always debugging layers of stacks of code… this layer talks
to some other layer in the horizontal... you need to solve the problem and you
don't know what's going on.” -Senior SDE, Windows Services
Some informants felt that the ability to handle complexity
was a natural ability. Others felt that great engineers could
effectively augment their natural abilities using tools and
processes (e.g. externalizing knowledge by writing it down):
“Ability to capture… simulate the architecture in their head… there's probably
a little bit of innate skill and cognitive ability… That said, the fact that you
don't have that skill doesn't mean that there's no other ways of doing it that
may be more brute force… writing things down and studying very carefully
the architecture you've put down is putting the brute force time into studying
a problem.” -Partner Dev Lead, Windows
C. Teammates
Informants mentioned 17 attributes of engineers’
interactions with teammates (see Table 4). Informants felt that
great engineers were expected to positively impact teammates.
For many informants, this was an important part of their job as
leads or managers.
Attributes in this area revolved around four concepts: being
a reasonable person, being a good leader, communicating
effectively, and building trust. We discuss, in detail, attributes
related to communicating effectively and building trust, as these
concepts are frequently mentioned in the literature but often with
little contextual understanding.
1) Creates Shared Context
Informants felt that creating shared context, which involved
molding another person’s understanding of a situation, was the
most important aspect of “communicating effectively”. This
involved tailoring the message to another person’s perspective:
“You perceive who you are talking to, and you are able to judge on those levels
that they are, or you just ask important questions. Do you know about this?
And then, be able to simplify the problem to the level that they’re working in,
or you estimate the amount of information given to them.” -Senior SDE,
Windows
This sentiment is closely related to the concept of
“grounding” proposed by Clark and Brennan, which, when done
successfully, required parties to “coordinate the content and the
process” of communication [30]. Since the engineering of
software involves many people, getting everyone to have a
shared understanding was seen as essential to success:
“One person can only accomplish so much so you've always got to be working
as part of the bigger group. People who can't communicate are only going to
be sort of so-so effective…” -Principal Dev Lead, Corp Dev
Informants also stated that great engineers, especially ones
at higher-levels, often had to communicate with people that do
not have a complete (or the same) understanding of the situation
but are critical to success (e.g. partner teams, customers, or
management). Therefore, crafting the message such that others
can comprehend the situation was important:
“Our areas where the things are inherently difficult to talk about… business
partners or with a customer… When you go outside and you talk to customers,
they think about things in much different terms and so in some ways you have
to kind of switch gears… why you should care about it and here is how you
should think about it.” -Principal Dev Lead, Corp Dev
2) Creates Shared Success
Informants described great engineers as creating shared
success for everyone involved, possibly involving personal
compromises. Informants felt that software engineering was a
collaborative process, requiring many people, often with
different personal motivations and organizational objectives.
Great engineers needed to get everyone making decisions
aligned to a shared goal:
7. “No matter how good is our code, if our partner [sic] cannot give it a good
product for us then we cannot share our greatness to the whole world. A lot
of time I see our support to our client is not very well [sic]… we should have
a good result combined together.” -Senior SDE, Phone
Many informants said that great engineers made shared
success bidirectional between managers and individual
contributors. Managers needed to put engineers in positions to
succeed; great engineers needed to engage management to
facilitate mutual success. Great engineers often had better
understandings of the details; managers often had a broader
perspective of the situation:
“It's a two-way communication… there's something going to happen down the
road, this piece of code or this feature going to have some issues, need to make
your manager aware.” -SDE2, Phone
This attribute likely helped to avoid dysfunctional ‘time
famine’ situations as discussed by Perlow [31], where crises
arise in teams due to a lack of shared understanding about status
and objectives.
3) Creates A Safe Haven
Many informants described great engineers as creating a safe
haven where other engineers can learn and improve from
mistakes and situations without negative consequences. Usually
associated with leaders, informants felt that if engineers are
afraid of mistakes, then their growth would slow:
“Chasing after a career path or something… you will deliver your best
performance if you are not insecure… One of the challenges as a manager
people face these days is retaining talent because there is so much attrition
all over.” -Senior Dev Lead, Ad Platform
Informants also saw the lack of this attribute as a major
contributing factor for talent loss. Informants did not want to
work in environments where they felt insecure, and often
avoided those teams/organizations:
“If you make one mistake or don’t know something and you’re sort of dinged
by that… and you’re only judged if you say everything’s perfect even if it
isn’t… Then you start to have this really kind of I think dysfunctional
environment set up where everybody just doesn’t say the truth.” - Principal
Dev Manager, Windows Services
TABLE 4. GREAT SOFTWARE ENGINEERS’ ENGAGEMENT WITH TEAMMATES. ATTRIBUTES DISCUSSED IN DETAIL ARE IN BOLD.
Attribute and description Excerpt that capture interviewees’ sentiment
Creates shared context—molding another person’s
understanding of the situation while tailoring the
message to be relevant and comprehensible to the
other person.
“Most compellingly relate the value of that abstraction as it goes to non-abstract to very abstract to
each person… empathize with your audience... get them to get it.” -SDE2, Windows
Creates shared success—enabling success for everyone
involved, possibly involving personal compromises.
“Find the common good in a solution… express here’s the value for you... It’s a win-win situation.”
-Senior Dev Lead, Windows
Creates a safe haven—creating a safe setting where
engineers can learn and improve from mistakes and
situations without negative consequences.
“If you learn something from a failure, that’s a wonderful sort of thing… [but not] If you’re afraid
of getting smacked upside the head… encourage the people to experiment, possibly succeed,
possibly fail”. -Senior SDE, Office
Honest—truthful (i.e. no sugar coating or spinning the
situation for their own benefit).
“When you do make mistakes, you've got admit you made a mistake. If you try to cover up or kind of
downplayed mistake, everybody will see it, it's super obvious. It affects your effectiveness.” -
Partner Dev Manager, Corp Dev
Integrates contexts—integrating different contexts
together into their own understanding, including noticing
and asking questions about gaps and incongruities.
“Disparate ideas and pieces of information… put pieces together… asking good questions... organize
your thoughts that will help you make those connections.” -Principal Dev Lead, Dynamics
Well-mannered—treating others with respect, not
obnoxious about their title, accolades, or knowledge.
“Smart but not cocky… He’s the one who knows all the information. He never comes across that
way… [does not] make the other people seem like, ‘Oh, I feel so stupid.’ ” -Senior SDE, Windows
Services
Acquires context—effectively acquiring contexts and
knowledge from others.
“To get the software to work… each things need to be integrate together [sic]... learn from others and
you need to know the things others are working on.” -SDE2, Corp Dev
Not making it personal—divorcing oneself from personal
feelings and biases.
“You can have a very open and heated discussions. But it is all very professional; none of this is ever
taken personally.” -Principal Dev Lead, Server & Tools
Mentoring—instilling knowledge to others; helping others
improve.
“He’s seen stuff that you haven’t seen yet, and he’s willing to share his knowledge… Let’s spread
some of that good knowledge around.” -Senior SDE, Office
Raises challenges—pushing others to action, expanding
the team’s limits.
“…Shared confidence: so it's like he's done it and so you can do it… spark your imagination and your
sense of self confidence for you to boot strap yourself up.” -SDE2, Windows
Walking-the-walk—acting as the exemplar (e.g. using
good practices) for others to follow.
“I would like to model myself against that behavior (of a great software engineer)… it inspires me to
do the same thing.” -Senior Dev Lead, Ad Platform
Manages expectations—setting clear expectations,
updating them, and then delivering on them.
“Your leads, your managers … setting expectations, they know what you’re going to do, you do it.” -
SDE2, Servers and Tools
Has a good reputation—having the belief, respect, and
confidence of others to make good decisions.
“Build up that reputation and that trust through your years… worth of good deeds essentially, so that
when you make that recommendation, they go, I am going to listen to him.” -Principal Dev Manager,
Windows Services
Stands their ground—firm against outside pressure (e.g.
management), when appropriate, based on sound
principles
“He will say no, if he has to. If what they're asking him to do jeopardizes something else… stand up
and be brave about it.” - Principle SDE, Windows
Trading favors—creating personal equity with others. “Returning a favor here and there… above and beyond to help somebody else out and then somewhere
down the road that person has that extra good will to come help you out.” -Senior Dev Lead,
Windows
Personable—cool people that one would engage with in a
non-work setting.
“One of the characteristics I look for in every person that I get… Can I have a beer with this guy?
…but they’re very, very stubborn and you know that you can only put them on one thing and that’s
it.” - SDE2, Servers and Tools
Asks for help—finding and engaging others with needed
knowledge and information.
“He does his homework and anything that he doesn't know… he goes and finds a person that does
know. He doesn't try to know it all himself.”-Principal SDE, Windows
8. Though informants felt that safe havens were important,
many expressed the need to balance a safe environment with
feeling the pain of mistakes. The reasoning was that pain from
mistakes was the best teacher: if an engineer was hurt by
something, then the engineer quickly learned to avoid it:
“I believe in having people feel the pain of their own mistakes… dealing with
the ramifications of the decisions that are being made, I guess is the best way
to learn.” -Principal Dev Lead, Office
4) Honest
Informants felt that being honest was the most important
attribute related to ‘trust’. This was about great engineers
providing credible information. Engineers that presented a
version of the situation that suited their own benefits were
viewed negatively. Informants felt that they needed to be able to
take action based on information that an engineer provided:
“Influence comes to someone else trusting you, part of that trust is that they go,
‘You know what? I know that this person always speaks the truth.’ As a result
of that, when they say something is good, I will totally believe them because
they are not trying to kind of misrepresent something or make them look better
or whatever.” -Windows Services Principal Dev Manager
Informants also did not appreciate wasting time shifting the
blame for problems. They felt that great engineers focused their
attention and efforts on addressing the problem:
“Rather than thinking about how to actually fix the problem at hand, [other
engineers were] more like "How do I make sure that nobody will come back
and think that maybe that happened because of something that I might have
done?" [This great engineer] has a way of kind of saying: It doesn't
matter…What matters is right now. How do we actually work through it?” -
Senior SDE, Windows
D. Software Product
Informants mentioned 9 attributes regarding the software
that great engineers produced (see Table 5). Like artists
appreciating masterpieces of other artists, our informants, many
of whom are great engineers themselves, saw beauty in the
software produced by other great engineers.
1) Elegant
Informants described software of great engineers as elegant:
possessing simple and intuitive designs that another person (or
themselves later) could easily understand. Among all software-
related attributes, elegance was the most revered. Informants
recognized that some problems in software were complex and
highly constrained, making it difficult to have a simple solution
that met the requirements:
“The style… always, an idea, and it was all clean… very concise. Just looking
at it, you can say, "Okay, this guy, he knew what he was doing."… There's no
extra stuff. Everything is minimally necessary and sufficient as it should be.
It's well thought-out off screen.” -Windows, Senior SDE
Informants also felt that it was critical to avoid complexity.
Complex solutions increased the likelihood of bugs and
increased maintenance costs (if problems were fixable at all).
Evolving the software was also more costly when the design was
brittle to change:
“Never complicate any things… when you simplify things it becomes easier for
you to maintain, going forward for customers… You get lesser number of
issues reported by a customer.” -Senior Dev Lead, Dynamics
2) Creative
Many informants described the software of great engineers
as creative, involving novel solutions based on understanding of
the constraints of the context, existing solutions, and the
limitations of existing solutions. Informants felt that there were
two important parts to having creative solutions. First, great
engineers understood constraints and requirements of the
particular context/problem:
“If you're looking for really an innovative …or just a solution that’s outside the
current norm… think through the problem…constraints that are currently
imposed on the environment.” -Principal SDE Lead, Windows
Second, great engineers knew of and knew when to apply
existing solutions (and not be creative). This was important
because informants felt that known solutions were generally
preferable since they were less costly and less error-prone:
“You are now using all of your creativity to reinvent things that are already
invented and that is just basically wasteful.”-Principal Dev Manager,
Windows Services
Still, most informants felt that novel problems occurred
frequently in software engineering, needing great engineers with
the ability to come up with innovative solutions:
TABLE 5: GREAT SOFTWARE ENGINEERS’ SOFTWARE AND DESIGNS. ATTRIBUTES DISCUSSED IN DETAIL ARE IN BOLD.
Attribute and description Excerpt that capture interviewees’ sentiment
Elegant—simple and intuitive (i.e. not complex)
software/designs that others can understand.
“They are simple... very easy to understand in a sense that it’s very simple. Doing something well
and in a very simple way is very very hard.” -Principal Dev Lead, Bing
Creative—novel solutions based on understanding of the
context, existing solutions, and the limitations of existing
solutions.
“Think outside the box… here's a traditional solution… often have constraints...take the difficult
circumstance and actually make it into something that could actually still work, but without a
huge complex overhead.” -Senior SDE, Principal Dev Lead
Anticipates needs—producing software that
accommodate likely needs and problems based on
contextual knowledge
“Think where you're going to get into trouble potentially… What are we ultimately trying to do,
and what can I do today that will save me time over the lifetime of the system?” -Technical
Fellow, division removed to preserve anonymity
Makes tradeoffs—making trade-offs (e.g. quality for time to
market) based on the context and the situation.
“Weight the tradeoffs. Is this really the right thing to do?” - Principal SDE Lead, Windows
Attentive to details—paying attention to coding details
during development including error handling, memory
consumption, performance, and style.
“The quality of the code, performance, space, and how many bugs it has, how robust it is, and how
it handles exceptions will have great differences.” -SDE2, Severs & Tools
Fitted—thought-through designs that take the context (e.g.
other components) into consideration.
“You understand better, interactions around you or around your code. How your code is supposed
to work… if I tweaked this here I’m not going to break something else.”-Senior Dev Lead, Xbox
Evolving—structure the software to be efficiently delivered
iteratively or in pieces.
“A very clean step-wise process moving forward… how can we break this down so that we have
really concrete deliverables on an ongoing basis.” -Senior Dev Lead, Bing
Long-termed—acting with an eye towards the future, not just
short term gratification.
“A bunch of isolated, fragmented, short-term solutions together, what do you get? Not something
great. Definitely, someone needs to have this long-term vision and say: we make decisions not
based on the immediate problem…” -Partner Dev Manager, Corp Dev
Carefully constructed—using the right processes (e.g. unit
testing) to produce the software.
“Unit testing, of the code. Well before that was fashionable… almost no bugs ever found in the
product and that was actually his track record.” -Senior Dev Manager, Windows
9. “Understanding patterns and understanding how to apply something is very
important so you don’t recreate wheels all the time… when there isn’t an
obvious pattern… Are you creative enough… come up with something new?”
-Senior Dev Lead, Windows
3) Anticipates Needs
Many informants described software of great engineers as
anticipating needs, accommodating possible future requirements
not known at the time when the software was initially produced.
Informants commonly mentioned scale (e.g. more users),
feasibility (e.g. technology advancing to the point where new
things were possible), and integration (e.g. working together
with additional software products):
“QQ, the Chinese chat program. It now has hundreds of millions of users. That
system was designed fifteen years ago, when QQ only had a few million users.
It still works today, that’s amazing, to have a system that scales that well, to
foresee all the issues it would have to face.” -SDE2, Severs & Tools
More than any other attribute, informants discussed the
propensity to overly anticipate needs in the face of uncertainty,
incurring high costs to add unneeded flexibility. Some thought
that any prediction of the future was foolish and preferred to
design for current needs and being open to rewrites:
“‘..Architect something now that's going to survive well 20 years from now?’
Nobody is that smart to be able to predict the future that well, I will refactor
towards new requirements and I constantly do that.”-Senior SDE, Office
V. THREATS TO VALIDITY
As with any empirical study, our results are subject to
various threats to validity. There are threats to the construct
validity from the lack of a clear and shared definition of a
‘software engineer’. Though, in general, informants understood
that we meant people that wrote code to be used by customers,
and we clarified whenever there was confusion. Our interview
and analysis processes contain threats to internal validity.
Informants could generally only mention a few salient attributes
unprompted; given more time to think, informants may have
produced more attributes. Moreover, while our analysis was
systematic, other researchers may discern different attributes,
definitions, or models than ours. Our sampling method also
contain threats to external validity. Though our 59 interviews
yielded rich insights, it was a small sample, even for Microsoft,
which employs tens of thousands of engineers. This led to some
natural biases, such as underrepresentation of women; we had
only 3 among our 59 informants. In addition, we only sampled
engineers in Seattle, USA. Findings may not generalize to other
cultures, especially attributes associated with management. The
size of the organization may also affect generalizability,
especially for attributes related to people and organizations.
Microsoft also had an established set of practices, tools, and
products; findings may not generalize to other situations (e.g.
start-ups). Microsoft is a software-centric company; informants
discussed unfavorable conditions in non-software centric
industries, like finance and retail. It is unclear whether the same
attributes (or their standards) would generalize. Nonetheless,
since Microsoft is a successful organization that produces
software used by billions, findings are relevant and interesting.
VI. DISCUSSION
Overall, nearly all of the attributes of great software
engineers we uncovered have been mentioned to some degree in
prior work, e.g. [1][3][27], and many attributes overlap with
ones important to other professions, e.g. [11][21]. Our results,
however, are the first time a comprehensive set of attributes for
software engineering has been identified and described. In
addition, there are several important implications. First, our
results suggest that productivity is only one criterion for
excellence. How the engineering is conducted, relative to
management (e.g. managing expectations), subordinates (e.g.
creating a safe haven), teammates (e.g. asking for help), partners
(e.g. creating shared success), and even oneself (e.g.
perseverant), are all critical. This reinforces the perspective that
software engineering is a sociotechnical undertaking, and not
just a technical one. Furthermore, simply delivering the code is
also insufficient. With attributes like elegant, creative, long-
termed, and seeing the forest and the trees, our results indicate
that good software engineering requires engineers to make
complex, experienced-driven, contextual considerations.
Second, though rarely discussed in the software engineering
literature, results suggest that effective decision-making is
critical. Informants felt that there are usually myriad options—
not all good—for what to do and how to do it. And as engineers
grow in their careers, they are tasked with making decisions in
increasingly more complex and ambiguous situations, often with
significant ramifications. Making effective decisions, entailing
attributes in Section IV.B as well as other sections, is an
important skill for engineers to develop.
Third, results suggest that being able to learn new technical
skills is likely more important than any individual technical
skills. Informants, even ones in the same division, used diverse
technologies—sometimes project specific tools (e.g. Cosmos, a
Microsoft version of Hadoop). There was no consensus on any
specific technical topic (e.g. architecture) as being essential.
Rather, most informants stressed needing to learn new skills (i.e.
continuously improving) and nearly all viewed it as a critical
attribute of great engineers.
The attributes we have identified and described may have
wide-ranging implications for researchers, novice engineers,
managers, and educators. In the rest of this section, we discuss
implications and opportunities to build upon our results.
A. For Researchers
Our findings raise important questions about our current
understanding of what affects software engineering outcomes.
Much of the prior work on this topic focuses on processes [32],
cost-estimation (e.g. COCOMO [33]), coordination [34], and
requirements engineering [35]. While many of the attributes we
uncovered underlie these concerns, such as creating shared
context and carefully constructed, there are also others that have
not been considered, such as aligned, creates a safe haven, and
fits. These likely reflect higher-level concerns such as
individuality, organizations, and productization.
Our results also suggest several new directions for tools
research. For example, we are not aware of any tools that help
engineers be more well-mannered in emails or evaluate tradeoffs
and see the forest and the trees when making decisions. Tools
research may explore facilitating and training engineers,
especially novices, in these attributes
10. An important part of better understanding these attributes is
developing measurements that operationalize these attributes.
These may enable rigorous science to better understand how the
attributes vary and their effects on teams and outcomes. Such
measurements may also form a critical foundation for managers
to identify and cultivate talent, for novices to improve, and for
educators to assess learning outcomes.
B. For Novice Engineers
New software engineers are often unsure of how to become
great engineers [1]. Our findings enumerate a set of attributes
that they might aspire to achieve. Improvements might come
from trainings, projects at work, mentoring, or self-adjustments
(e.g. for personality traits). Researchers might also investigate
interventions that help achieve the attributes quickly and
effectively.
Furthermore, novice engineers may also use our results to
assess their fit with prospective employers. As mentioned in
Section IV.A.2 on passionate, the fit of the engineer with the
project is critical. Novice engineers might assess their fit, in
terms of the attributes they value, with a prospective team.
Our findings may also help novices better present themselves
to employers. Since experienced engineers and managers value
these attributes, novice engineers might consider demonstrating
to employers that they have or can develop these attributes. This
also extends to highlighting the qualities when authoring their
resumes or presenting themselves in interviews.
C. For Managers
Our informants discussed many attributes that were
important for engineers in senior and leadership positions, such
as mentoring, raising challenges, and walking-the-walk. New
research may explore ways to help engineers improve these
attributes to become better managers.
Beyond improving themselves, our results may also help
managers make more effective hiring decisions. Managers may
better identify candidates that fit the culture and context of the
team. They may also better avoid engineers without the
attributes, such as not aligned (off doing their own projects), not
well-mannered (being an ‘ass’, as many engineers described it),
or not asking for help.
Finally, our results strongly suggest that managers may
consider cultivating the attributes within their teams. Managers
may consider using the findings—with help from further
research—to build a culture that is conducive to attracting,
producing, and retaining great engineers.
D. For Educators
Our findings also raise significant questions about
curriculum choices, teaching methods, and learning objectives
in formal computer science and software engineering education.
Educators may consider adding courses on topics not found in
their current curricula. For example, we found decision making
to be a key part of software engineering, but this specific topic
is not a part of the ACM’s Computing Curricula [6]. A course
specifically about decision making (e.g. discussing Simon’s
model of rational choice [36], Klein’s naturalistic decision-
making approach [37], or case studies of software engineering
decisions), might be valuable to students.
Software engineering educators might also use our results to
examine their teaching methods. Most attributes of great
engineers focus on how rather than what, whereas most
instructions in software engineering focus on teaching skills and
knowledge (the what), such as prior work on tools for automated
testing and analysis. Educators might consider improving how
software engineering goals are attained. For example, existing
project-based courses might use attributes presented in this paper
to help student evaluate each other’s behavior, as well as grading
non-functional attributes of the code, such as elegance,
anticipates needs, and creative.
Finally, educators might consider explicitly discussing what
students will not learn in school, allowing them to be aware of
potential knowledge gaps and empower them to seek out
opportunities outside of the academic setting (e.g. internships or
open-source projects). For example, attributes like self-reliant
may not be reasonable to teach in an academic setting and might
be better learned through mentorship on the job; nevertheless,
educators should consider informing students that it is a critical
component of software engineering expertise.
VII. FUTURE WORK
Though this paper is a good start at better understanding
software engineering expertise, there are countless opportunities
for future work. The combinations of attributes that are
interesting or prevalent could be examined. Each specific
attribute we uncovered in this study could also be the subject of
future empirical studies to provide deeper and more nuanced
definitions, approaches for measurement, or assessments of
impacts on software engineering outcomes. Comparison of the
attributes of software engineering expertise to attributes in other
fields could provide more insights into the unique qualities of
the software engineering phenomenon.
Our results provide little insight into the relative importance
of the attributes (e.g. weighting or criticality) and the effects of
contextual factors (e.g. gender or background). We did not
conduct an analysis for those insights for our interview study
because it would have lacked validity. We did not ask informants
about all the attributes, and informants often agreed or amended
their thinking when prompted with attributes from other
interviews. Future studies can examine this rich area.
With studies like these and the many others that our findings
provoke, our research community can begin to understand
software engineering not just as a purely technical discipline of
tools and processes, but a sociotechnical one, with individual
human contributors and their collaborations fueling software
progress.
ACKNOWLEDGMENTS
This work was supported in part by Microsoft, Google, and
the National Science Foundation (NSF) under Grants CCF-
0952733, CNS-1240786, and IIS-1314399. Any opinions,
findings, conclusions or recommendations are those of the
authors and do not necessarily reflect the views of NSF.
11. REFERENCES
[1] A. Begel and B. Simon, “Novice software developers, all over
again,” Int’l Computing Education Research Workshop, 2008,
vol. 1, no. 425, pp. 3–14.
[2] M. Hewner and M. Guzdial, “What game developers look for in
a new graduate: interviews and surveys at one game company,”
ACM Technical Symposium on Computer Science Education,
2010, pp. 275–279.
[3] L. Gugerty and G. M. Olson, “Debugging by skilled and novice
programmers,” ACM Conference on Human Factors in
Computing Systems, 1986, pp. 171–174.
[4] J. D. Valett and F. E. McGarry, “A summary of software
measurement experiences in the software engineering
laboratory,” Hawaii Int’l Conference on System Sciences, 1988,
pp. 293–301.
[5] H. Sackman, W. J. Erikson, and E. E. Grant, “Exploratory
experimental studies comparing online and offline programmmg
performance,” Communications of the ACM, vol. 11, no. 1, pp.
3–11, 1968.
[6] R. Shackelford, Andrew McGettrick, Robert Sloan, H. Topi, G.
Davies, R. Kamali, J. Cross, J. Impagliazzo, R. LeBlanc, and B.
Lunt, “Computing curricula 2005: the overview report,” SIGCSE
Bulletin, vol. 38, no. 1, pp. 456–457, 2006.
[7] T. C. Lethbridge, J. LeBlanc, R.J., A. E. Kelley-Sobel, T. B.
Hilburn, and J. L. Diaz-Herrera, “SE2004: recommendations for
undergraduate software engineering curricula,” IEEE Software,
vol. 23, no. 6, pp. 19–25, 2006.
[8] C. S. Miller and L. Dettori, “Employers’ perspectives on it
learning outcomes,” Information Technology Education, 2008,
pp. 213–217.
[9] E. M. Trauth, D. W. Farwell, and D. Lee, “The IS expectation
gap: industry expectations versus academic preparation,” MIS
Quarterly, vol. 17, no. 3, pp. 293–307, 1993.
[10] T. C. Lethbridge, “A survey of the relevance of computer science
and software engineering education,” Conference on Software
Engineering Education and Training, 1998, pp. 56–67.
[11] R. E. Kelley, “How to be a star engineer,” IEEE Spectrum, vol.
36, no. 10, pp. 51–58, 1999.
[12] D. M. S. Lee, E. M. Trauth, and D. Farwell, “Critical skills and
knowledge requirements of IS professionals: a joint academic /
industry investigation,” MIS Quarterly, vol. 19, no. 3, pp. 313–
340, 1995.
[13] E. Brechner, “Things they would not teach me of in college : what
Microsoft developers learn later,” ACM SIGPLAN Conference
on Object-oriented Programing, Systems, Languages, and
Applications, 2003, pp. 134–136.
[14] E. W. Dijkstra, “The humble programmer,” Communications of
the ACM, vol. 15, no. 10, pp. 859–866, 1972.
[15] A. Bryant, “In head-hunting, big data may not be such a big deal,”
The New York Times, 2013. [Online]. Available:
http://www.nytimes.com/2013/06/20/business/in-head-hunting-
big-data-may-not-be-such-a-big-deal.html.
[16] S. McConnell, Code complete: a practical handbook of software
construction, 2nd Edition. Microsoft Press, 2004.
[17] M. T. H. Chi, R. Glaser, and Ernest Rees, Expertise in problem
solving. University of Pittsburgh, 1981.
[18] J. W. Alba and J. W. Hutchinson, “Dimensions of consumer
expertise,” Journal of Consumer Research, vol. 13, no. 4, pp. 411–
454, 1987.
[19] M. P. Robillard, W. Coelho, G. C. Murphy, and I. C. Society,
“How effective developers investigate source code : an
exploratory study,” IEEE Transactions on Software Engineering,
vol. 30, no. 12, pp. 889–903, 2004.
[20] K. A. Ericsson, R. T. Krampe, and C. Tesch-romer, “The role of
deliberate practice in the acquisition of expert performance,”
Psychological Review, vol. 100, no. 3, pp. 363–406, 1993.
[21] H. Simon, Administrative behavior, 3rd ed. The Free Press, 1976.
[22] D. H. Gobeli, H. F. Koenig, and I. Bechinger, “Managing conflict
in software development teams: a multilevel analysis,” Journal of
Product Innovation Management, vol. 15, pp. 423–435, 1998.
[23] J. Anvik and G. C. Murphy, “Determining implementation
expertise from bug reports,” Int'l Workshop on Mining Software
Repositories, 2007, pp. 298–308.
[24] G. Jeong, S. Kim, and T. Zimmermann, “Improving bug triage
with bug tossing graphs,” European Software Engineering
Conference and the ACM SIGSOFT Symposium on the
Foundations of Software Engineering, 2009, pp. 111–120.
[25] A. Podgurski, D. Leon, P. Francis, W. Masri, M. Minch, J. Sun,
and B. Wang, “Automated support for classifying software failure
reports,” Int'l Conf. on Software Engineering, 2003, pp. 465–475.
[26] P. Runeson, M. Alexandersson, and O. Nyholm, “Detection of
duplicate defect reports using natural language processing,” Int’l
Conference on Software Engineering, 2007, pp. 499–510.
[27] D. Bertram, A. Voida, S. Greenberg, and R. Walker,
“Communication, collaboration, and bugs: the social nature of
issue tracking in small, collocated teams,” ACM Conference on
Computer Supported Cooperative Work, 2010, pp. 291–300.
[28] J. Aranda and G. Venolia, “The secret life of bugs: going past the
errors and omissions in software repositories,” Int’l Conference
on Software Engineering, 2009, pp. 298–308.
[29] J. M. Corbin and A. Strauss, Basics of qualitative research:
techniques and procedures for developing grounded theory,
Fourth Edi. SAGE Publications, Inc, 2014.
[30] H. Clark and S. Brennan, Perspectives on socially shared
cognition. American Psychological Association, 1991.
[31] L. A. Perlow, “The time famine : toward a sociology of work
time,” Administrative Science Quarterly, vol. 44, no. 1, pp. 57–
81, 1999.
[32] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M. Paulk,
“Software quality and the Capability Maturity Model,”
Communications of the ACM, vol. 40, no. 6, pp. 31–40, 1997.
[33] B. W. Boehm, C. Abts, A. W. Brown, S. Chulani, B. K. Clark, E.
Horowitz, R. Madachy, D. J. Reifer, and B. Steece, Software cost
estimation with COCOMO II. Prentice Hall, 2000.
[34] J. D. Herbsleb and A. Mockus, “Formulation and preliminary test
of an empirical theory of coordination in software engineering,”
European Software Engineering Conference and ACM SIGSOFT
Int’l Symposium on Foundations of Software Engineering, 2003,
pp. 138–147.
[35] B. W. Boehm, “Verifying and validating software requirements
and design specifications,” IEEE Software, vol. 13, no. 2, pp. 25–
35, 1996.
[36] H. Simon, “A behavioral model of rational choice,” Quarterly
Journal of Economics, vol. 69, pp. 99–188, 1955.
[37] C. E. Zsambok and G. Klein, Naturalistic decision making.
Lawrence Erlbaum Associates, 1996.