Eight to Late

Introduction

The relationship between software developers and project managers is often fraught with  conflict.  Yet they have to get along professionally:  the success of a software project depends to a large extent on whether or not they can work together. A paper entitled Stop whining, start doing! Identity conflict in project-managed software production, published in the May 2009 issue of Ephemera, delves into this issue by looking at how the two parties view themselves in relation to each other.  This post is a summary and review of the paper.

A quick word or two before diving into the paper. First, identity conflict occurs when a person or a group feels that their  sense of self (i.e. their identity) is threatened or denied legitimacy and respect. Second,  although the title of the paper suggests that  it deals with identity conflict in project-managed software production, the authors’ focus is considerably narrower: the analysis presented in the paper is based on selected Slashdot discussion threads involving software developers and project managers.  In effect, the authors draw their conclusions about identity conflict in software production based on  opinions expressed online forums.   It is, I think,  stretch to read too much into such exchanges. I’ll have more to say about this in the final section of this post.

The authors of the paper, Peter Case and Erik Pineiro, begin their analysis by noting that although project managers are usually above programmers in the organizational hierarchy, the relationship is complicated by two factors:

1. Project managers usually do not need (and often lack) the educational qualifications possessed by programmers.
2. Project managers usually do not have the depth of technical knowledge that programmers have.

These two conditions often lead to the view amongst programmers that they (the programmers) have a higher organizational status (or matter more) than project managers do.

The authors end their introduction with the observation that the skills of programmers are necessary for the creation of software, but equally necessary is the need to direct software building efforts using some form of project management. This observation underlines the symbiotic relationship between developers and project managers. On the other hand the differences between the two disciplines is also a source of conflict between the two parties. The main aim of the paper is to highlight how this conflict plays out  in online discussions involving developers and project managers.

Research Methodology

Case and Pineiro base their research on an analysis of contributions to online discussions on Slashdot. A large number of Slashdot contributors are programmers. The discussions cover a range of topics of interest to coders – from the merits of particular technologies, to outsourcing, aesthetics and personal philosophies of  programming. The authors use two ideas (or, more accurately, lenses) to interpret the data, the data being individual contributions to discussions.

First, the authors contend that contributors to Slashdot are:

… bringing about  social effects through their displays of technical bravado, expressions of aesthetic preference and espousals of dissent, resistance and subversion.

In particular, when discussing the relationship between programmer and project managers, contributors – through the discussion – are creating (or confirming) a certain view of the relationship between the two parties.  In doing so, they are enacting their own identities (as members of a particular guild). They do so in opposition to the other party – i.e. by setting themselves apart by negating the  skills, knowledge and work of the other.

Second, the work that programmers do has a certain value in the marketplace – i.e it is created because of its (direct or indirect) commercial value. This has two consequences:

1. Programmers feel that they have to compromise on quality (or aesthetics) because of time pressures and, on the other hand, project managers feel that programmers do not understand the commercial imperative to move the project forward.
2. Both sides feel that their own specialized area of knowledge – technical or managerial – is the truly important one  as far as the commercial aspects of the project are concerned.

The authors use excerpts from Slashdot discussions to highlight these two dynamics at work.

Data analysis and discussion

The programmers’ perspective

In Slashdot discussions, Case and Pineiro find that programmers articulate different identities depending on the audience. In some situations they express an interest in (or agree with the importance of) meeting deadlines, getting the product to market etc. Whereas, in other situations, particularly when responding to (or comparing themselves to) project managers, they might express an interest in code aesthetics – i.e. the importance of writing good, even beautiful, code. Several examples of the latter can be found in a discussion thread on software aesthetics. Many of the contributions to the discussion assert that (good) programmers have the following traits:

• Are passionate about their work
• Care deeply about quality.
• Understand of the importance of good code.

Several contributors make these points in opposition to the work-related traits of managers. That is, they set up a stereotypical manager – who doesn’t care about code quality etc. – as a foil for their rhetorical arguments.

Technical knowledge is another important way in which programmers set themselves apart from project managers. The contention here is that managers cannot really understand what a software system is because they don’t have the required knowledge; an implication being that they are not qualified to manage its construction. Case and Pineiro mention how this issue can really raise emotions when it comes to the issue of outsourcing (see this discussion thread for example).

The project manager’s perspective

Although the Slashdot community is dominated by programmers, the authors were able to find a few contributions that gave the project managers’ viewpoint. For example, a discussion on project management for programmers, gave some project managers an opportunity to articulate their views. In the discussion, project managers tended to focus on two aspects – performance (i.e. completing the project on time) and project management knowledge – both of which (they implied) programmers do not understand. See this comment for an example of the former and this one or this one for examples of the latter.

Project managers thus set themselves apart (i.e. construct their identities) as distinct from programmers. They are concerned with driving the project to successful completion and they have specialized knowledge and training to do this; both of which programmers do not possess.

The authors’ conclusions

From their analysis of selected Slashdot discussions, Pineiro and Case conclude the following:

1. Software developers and project managers tend to construct their identities in opposition to each other – i.e. by setting themselves (their skills, motivations and concerns) as being different from the other. On the other hand, business imperatives require that they collaborate, so there is a symbiotic aspect to their relationship.
2. Despite project managers being marginally higher up than programmers in organizational hierarchy, there is little difference in the status of the two. The reasons for this are: 1) Project managers lack the specialized technical knowledge needed to understand programmers’ work and 2) Software project managers’ are dependent on programmers – perhaps more so than project managers in other disciplines. As a consequence, the difference in status might rankle with programmers. Thus the hierarchical proximity of the two parties might also be one of the reasons for the conflict between the two.
3. Both parties generally claim to have the same goal – produce quality software in reasonable time. They differ, however, in the means to achieve the goal. Programmers believe the focus should be on producing high quality code whereas project managers tend to emphasise the optimization of resources and time, whilst meeting the system requirements.

Wrapping up

The paper isn’t an easy read because of the wide use of sociological jargon,  but then it is a research paper. The central idea –  that online discussions can serve to construct or reinforce programmer and project manager identities – is an intriguing one.  If true, it implies that one’s self (and projected) image influences,   and is influenced by,   how one describes oneself to others in speech or writing.   For instance, does my claim that I’m a “seasoned database architect” and “experienced project manager”  reinforce my professional identity? Also interesting is the idea that developer and project manager identities are often constructed in opposition to each other. That is,  both parties appear to build their identities by casting the other in a negative light.

However, as interesting as  all this is,  I believe it misses a crucial point:  that programmers and project managers, for the most part, play out roles which are defined and enforced  by the organisations they work for. If organisational rules and norms require programmers (or project managers) to behave in dysfunctional ways,  then that’s exactly what most of them will do.  On the other hand, if  an organisation encourages behaviour that fosters good working relationships between the two parties, things would be different:  those working in such environments  would have more positive experiences to to relate (this comment taken from one of threads analysed by the authors is a case in point). It is surprising that the authors chose not to include such (positive) comments in their analysis.

In brief:  the paper  presents an interesting perspective on the relationship between programmers and project managers.  Even though the authors’ focus is somewhat limited, the paper  is of potential interest to researchers and practitioners interested in work relationships in project environments.