exploring the relationship between social science and software development methodologies: a blog by Pascal Belouin

Although only remotely connected to what should be the main concern for software development projects (that is to say that the specifications are right), the interplay of power relationships between stakeholders can really cause a lot of damage. I am not talking only about tensions that may arise between, for example, the sales team and the development team in a typical web company (or organisational politics, as I’ve discovered they’re called), but also of the sometimes delicate relations between organisations involved in the same project (inter-organisational politics?). It may be even be possible to argue that differences of agenda between the various stakeholders of a project are amongst the main causes of distasteful phenomena such as deadline slippage or scope creep.

The root of this problem may be found in the good old issue sadly familiar to us, people who design things for a living: everybody is a designer (and my nephew builds websites in his bedroom).
Indeed, the fact that our profession is still relatively young makes it even more difficult to use the authority that should be bestowed upon us as designers or developers so as to make sure that particular design decisions (hopefully the right ones) are made. Instead, these decisions too often end up being made by people sometimes not at all aware of the implications of such decisions on the project as a whole. Thus, developers and domain experts end up either near the bottom of the decision chain or even invisible: This can sometimes have rather dreadful and indeed stressful consequences for everybody.

Furthermore, development disasters, which are abundant in software development history, do not help in reassuring stakeholders that everything will be kind of sweet and that yes they made a lot of errors in the past but this time everything is going swell and this one won’t turn into a financial blackhole.¬†Hopefully, I’m not the first one to make this diagnostic, and I wonder if the authors of the agile manifesto did not have this issue painfully in mind when trying to come up with software development methodologies designed to respond to change!

So how can such power struggles become such as strain on a particular software project? and more interestingly I guess, how can we avoid this? For all of you big wigs, from a medium-to-small wig, here are a couple of things to watch out for!

  • Don’t take design decisions lightly!
  • Although it may be tempting, do not take design decisions if you do not have a clear understanding of both the domain and the system as it is being built! I noticed this quite a lot in a few places, and it really can cause damage, as the addition of any feature, even trivial (“it’s only an extra check-box”), can have a strong impact on the architecture of the system, and imply a number of changes in the code base and in the interfaces that may not be necessary; Discussing the issue with people who know exactly how the system works and have a fair knowledge of the domain will certainly provide more insight into the problem that needs to be solved, and most of the time a solution that fits everybody will be found!

  • Trust (and love) your developers!
  • Your developers are a precious investment, a bit like Kobe beef: You need to make sure they’re not stressed out so that the meat stays delicious. Thus, if you have a stake in a software project, make sure you get to know the developers at least a little bit, and make sure you can email them freely if need be. As most people like me try to hammer to death, communication (and therefore, trust) between management, domain experts and developers is really a determining factor of success for software development projects. Thus, even if it may sound like a good plan, it is not a very good idea to delegate your relationship with development teams to members of your team, or consultants. Don’t get me wrong, in general it’s always nice to get as much help as we could get, but your developers will definitely feel alienated from you if you do not try and communicate directly with them at least a bit.

Related posts:

  1. Social science for software developers – Using tools from social science to inform software design: should software developers also be social scientists?
  2. Interface Design and Information Architecture for Enterprise Web Applications: Four Simple Principles
  3. Research proposal : A Foucauldian analysis of the evolution of the discourse about software development methodologies
  4. Outside-in Web Application Development: The advantages of building production-ready static html prototypes as interface mock-ups
  5. The Emergence of Meaning Through System Use: The central role of interaction and its implications in terms of design methodology

Leave a Reply