Monday 13 April 2009

Software Development is a Social Activity

Something I have been pondering for a while, is "Why is software so hard?". I know it is hard, I have spent a long time working in the industry, I have seen it fail - thankfully I have seen it succeed (albeit often "challenged") more regularly. I have read a lot of books and talked to a lot of people, but still I felt something was missing.

Computers are logical devices, they follow your instructions exactly without the slightest deviation - however being human we are not logical, and we do not execute or think naturally in the same precise logical manner. Our brains are non-linear, we make jumps, we shift through varying layers of abstraction and we rarely stay in that logical state for too long.

But that still doesn't explain why software is so hard. We also have the tools to focus us and guide us when it comes to writing the code. Compilers, unit tests, analysis tools, exploratory testing as well as a myriad of processes attempt to focus us on the problem at hand. So why is it still so hard?

I think one of the leading reasons is this, Software Development is a Social Activity and those that work in software development are stereo-typically anti-social in nature. Yes it is a stereo-type, but it does have a firm foundation in the truth. By in large, we are not social butterflies, we tend to prefer the company of machines to that of humans, the company of our problem domain to that of other people. I hear cries of disagreement from some quarters - yes it is not the rule, there are some highly sociable developers out there.

However time and time again, I have seen software projects flounder because of the lack of both information and 'social' bandwidth. By social bandwidth I mean the social interactions between members of the team. Good social bandwidth from my experience requires a very high information bandwidth - face to face communication is good example. This is somewhat difficult to explain, and something I feel that I am only beginning to grasp.
Email has perhaps one of the narrowest social bandwidths of all. You have no real sense of the other persons state of mind, their current emotion or their current physical situation. Its even narrower when one or even both parties don't recognise that fact. We have all witnessed email storms caused by an off the cuff comment at one time or other.

An area of high social bandwidth is the office coffee machine or water cooler. Where people tend to meet, talk and exchange idea's purely because of the constructed environment - you would not choose to go and chat to a random person every hour or so just for the hell of it (... or maybe you would, maybe you are one of those social butterflies).

Location is a key factor here, as we congregate together to work, we construct a village, a place of community. Now communities don't always get on, and certainly are not all best friends - but they do tend to build a spirit over time, especially where interaction is unavoidable.

The act of developing a piece of software is the act of a community, it requires a varied team. Just as the village requires the butcher, the baker and the candle-stick maker. The most productive teams recognise and encourage that variation in skills, and tend naturally strive to increase their social bandwidth to spread those skills and experience.

Too many times I have heard a senior manager, who having walked into the office for 30 seconds in a month, complain that a team is not working hard enough - when I know what they heard was actually the sound of productivity, the sound of high information and social bandwidth. A team with a strong bond, can have a chat or a laugh - a positive working environment increases productivity, it makes people want to come into the office.

Now I am not saying the team needs to hold hands and sing campfire songs, but rather the team needs interaction. It needs developers, testers, business analysts, project managers and customers to interact. And the team should foster that interaction both professionally and socially. I've seen project managers turn down a pub lunch request which would have done wonders in building a fragile relationship into something more substantial.

It is important that this social drive come from within the team, and not an enforced company social event, one which will leave some feeling awkward or even resentful, and actually discourage some from attending at all. A sense of professionalism can provide that balance, and it is more than achievable with the right team.

No comments: