Reg readers: Distributed software development is hard

The Reg reader poll run earlier this week as part of our agile development workshop produced a set of results that do not paint a particularly inspiring picture. When asked how distributed software development was managed within organisations, almost half told us things were not that great. About a third gave feedback indicating …

[Solomon Grundy]

Survey Design

I participated in the survey that generated the results in this article. While answering the questions it became quite obvious that there was a secondary, undefined, purpose for the survey.

For example if you (survey participant) indicated that you did not distribute your development operations then you were still presented with contextually nonsensical questions...

It was either a poorly designed survey (possible) or designed to sell market analysis data to targeted 3rd parties (probable) who in this case seem to be "Social Networks", which can alleviate lots of the problems traditionally associated with development. Hahahaha. Hahahaha. The last page of this article says it all...

[Dale Vile]

Survey design

@Solomon - sorry about the lack of routing in the poll- you make a good point and we pay a lot of attention to this in our more in-depth reader surveys. We try to keep short 'temperature check' polls like this one pretty simple, however, as they tend to be completed by people with an interest in or experience of the topic, which is true in this case (4 out of 5 respondents were into distributed development to one degree or another).

On your second point, let me put your mind at rest about motivation. This exercise has nothing to do with selling market analysis data to targeted 3rd parties - it is about drawing out hopefully useful insights from readers for the benefit of other readers.

Regarding the social media related findings, this is something that just hit us in the face as we were analysng the data. The correlation we saw between the use of blogs, wikis, etc and a reduction in the four specific problem areas shown on the chart was quite unexpected, and significant enough, we thought, to call out as a thought provoking point. I can assure you that there is no hidden agenda here that has anything to do social networking vendors.

I infer from your comments, though, that you are a bit of a sceptic about the social media thing. It would be interesting to hear more about your thoughts here - or, indeed, if you have an alternative way of interpreting any of the findings. The reason for publishing the charts is precisely so readers can make their own judgement without relying on purely on our commentary - though we are pretty committed to keeping our interpretation both grounded and objective.

[Britt Johnston]

Try again, please

I didn't participate in the survey, because I'm only a data manager (=user with funny ideas) who happens to sit in the same office as an even mix of about 150 from India and internal IT working on a global SAP implementation. But I also don't agree that blogospherics would improve the stresses I currently observe. There IS constant talk, and passing on of information, though often enough analysing what went wrong, or what is really needed.

In our case, the workflow and responsibility is also pretty well solved (accepting a time and documentation penalty) which is currently leading to an interesting work-to-rule from the out-side after adding a complex SAP module.

The bottom line is that our case ducks the old IT adage that one good programmer is worth lakh average ones, so you want the good guys in the right places. At the moment we keep our head above water, among other fixes, with pensioners rehired as consultants.

You could bring much to light as journalists if you sat down and discussed in depth with a few of the willing who answered the questionnaire.

[W.Hower]

@Solomon

Good to see your a big developer Solomon. Not only do you fail to understand the premie of the points being made, but you also completely fail to understand your own point.

When it says, 'Social Networking' tools it's not talking about facebook you. It's talking about collaborative work environments and, as I'm sure you would be aware if you'd ever developed any software with a team, collaboration environments are critical.

You're comments are particularly poor since the entire article is about distrbuted development which explicitly requires some form of centralised collaboration environment - how else do you document, detail, discuss and resolve the challenges, over the phone?

That aside, I actually through this was a really interesting article that I for one will certainly be using to justify plans that are in my budgets for next year.

[jake]

What a waste of time

I took the "survey". I actually read all 6 (six!) pages of the results. What a mind-bogglingly useless waste of space. It comes off as if it were written by a wet-behind-the ears, newly minted degree, paper engineer who has just discovered that there is a world outside of academia ... and that (GASP!) there are issues with campuses that can be global ...

Seriously, who was the author targeting with this drivel? His boss?

[Solomon Grundy]

Survey Design

Thank you for your response Dave!

First off, if the purpose of the survey (useful insights) is only to benefit readers, how do you get paid? Doing something for "good" is great, but it doesn't get you on the bus....

Secondly, (which you addressed quite satisfactorily thank you) you point out there was a lack of routing in the survey - Doesn't that mean that all the results and analysis were off? (i.e. I/we participated in the survey but I don't do distributed development; so the relevance of any answers I provided is in doubt in the context of the survey. How many others did the same? We just don't know). If the survey routed "me" to another page (even 'exit') because I didn't meet your needs it would have been more valid.

Thirdly, as you can see by other comments, the term "social network(s)(ing)" is such a huge buzzword. It's "In The Cloud" and has meaning only to the person answering. Some people consider SourceSafe a collaborative environment... Some people consider a local Windows Network a social network.... You did provide a few examples (Wiki's, etc...) but the term "social" is lacking in regards to collecting scientifically valid data.

[Solomon Grundy]

@W.Hower

It's nice to see you're a big whiner W.Hower. Not only do you fail to understand the failure of basic data collection concepts exhibited in this survey, you also look like a complete tool. Good on you!

As you need to understand, I don't develop software; I manage 41 software developers and 9 physical engineers focused on solving problems that you (hopefully) won't ever have to deal with. We sent $6 million to India in '04 and $8 million to Ukraine in '06 and it didn't work out at all. Therefore we decided to bring all our efforts in house. I've done everything they talked about in the article 20x over so I felt my input was valid.

You can read my response to the survey people that should put the rest of your comments in a socially acceptable perspective.

[Anonymous Coward]

Dsitrbuted Software Development is easy

Finding good software developers is hard.

Finding environments where good developers can operate optimally, and unfettered by structural management nepotism is hard.

But distributed development is simple :)

If you think any other way, then you are not a developer you are a day tripper, a tourist in the digital world :)

I personally don't participate in these questionnaires, what is the point they often miss out the root of the problem, and try and drive their own angle, they are pointless and their conclusions are obviously derived from people who don't know what they are doing if this is the result :)

Off shoring is hated because it reduces the value of the profession being off shored, it is that simple. It is taking future earning potential out of your pocket, so people don't make it easy for others to understand how to facilitate that position. Hell, most of us block India from looking at tech documents, dropping the connection to India is not a bad idea as well, why support the competition it is moronic.

[Dale Vile]

Sample size and distribution

Someone has pointed out that the sample size for the poll was not mentioned in the article - it unfortunately got lost from the charts during desktop publishing (Jamie? :-)).

For the record, there were 369 respondents, of which about 80% told us they had direct experience of distributed software development. As the article says, within this, there was a relatively even distribution of those taking the hub and spoke, peer to peer and ad hoc/mixed approaches to managing distributed activities, which gave us adequate numbers to compare the groups as we have done.

Geographic split was 44% UK, 36% USA and 20% elsewhere. The majority of respondents (90%) were from in house development organisations, with contractors and employess of external service providers together making up the remaining 10%.

[Anonymous Coward]

tool use takes labor not just money

The collaboration tools are interesting--they truly enable better communication, but the downside is that now you're forcing the (expensive) onshore staff to spend more time keeping wikis or whatnot up to date, negating some (occasionally all) of the cost savings you got from offshoring.

[Anonymous Coward]

Social networking and open source

Agree with W Hower, and let's not forget that social networking and collaboration plays a fundamental role in hard core open source communities, so we really shouldn't confuse it with all that touchy feely Facebook stuff. In fact, you could argue that in house developer groups working in big commercial organisations could learn a thing or two from how collaboration takes place on open source projects.

[Tuomo Stauffer]

Interesting study and comments

Doing global (and local) development since 70's, sometimes managing, sometimes designing, sometimes just coding or testing so I have seen X number different projects (and results!) There is also a difference between internal and external projects, and also if you are a provider overseeing (helping) a customer or another provider project - many flavors.

The study really hints what I have always thought and why I'm big fan of social networking and collaboration. And agile - long time before marketing came with that word.

The differences today are really all the tools and toys available. Used correctly they can be very useful but often misused and causing some problems. Earlier using for example phone and transferring massive amounts of documents, code, etc were very error prone, slow, and so on. Today there is no need for that, distributed systems take care of that. For design, negotiation, checks, etc just fire the video conference and whiteboards up in computer - almost as good as sitting in same room. I can do that 24h from home, helps a lot in global environment.

Now, some things haven't changed - the management of a project is still and probably will always be a lot of manual work! It just needs personal touch today as much as ever. Worst projects I have had are when some group on other side of globe are given very detailed definitions and too much autonomy. No contract,SLA, project plan, etc ever is perfect but some cultures see them that way and execute them to the letter but nothing else. Time to fly there and when one way is 16-26h it definitely isn't fun but if the other option is to negotiate over phone, take two-three weeks (or sometimes months!) to even start something then the flying over and managing it in place seems a good solution. And no - Six Sigma or whatever disciplines are good and needed but can't replace common sense!

So, technically distributed projects are not bad but the logistics! Even locally distributed projects can keep you busy, separate buildings, campuses, whatever combined with todays "management model" where we build the railroad from east, the other organization from west and some day we will meet - but half a mail apart!

[Anonymous Coward]

Biases and Missed Correlations?

I think we have both sloppy survey design and unsuportable inference from the results here. Also, lots of interesting compariosons that should have been made in the article seem to have escaped attention completely.

Some of the "results" may be simply caused by correlations between attitudes of respondents, rather than real world differences. Those with the hub and spoke approach think they do better that those with the other approaches - doesn't mean they actually do better, just means they think so. But those with the hub and spoke approach are the ones who believe in a strong centralised authority, and surely they will believe that if they are doing as directed by that authority then they are doing well - even if their results are not really much good at all. Those with the ad hoc approach maybe are perfectioists - rather than 1 size fits all they want to tune the system to fit each work area, and being perfectionists they will think they are doing badly if the results are not perfect - even though they may actually be doing very well. In effect there is a natural bias in these questions which means that those who think (perhaps wrongly) that they know it all will give "good" answers while those who know that they don't know it all will not.

Then it would have been useful to drawsome useful information from the "social networking tools" questions: for example, is there any correlation between the answers to the question on using these tools and the question on how well people think they are doing - we don't see the answer to that in this article. Is there a correlation betwen use of these tools and vhoice between hub&spoke,peer,and ad hoc development control models? It would have been nice too to see if there is any apparent correlation between willingness to outsource various develpopment satages and perceived success.

Then there is an outrageous leap of illogic - recognising that something is a problem apparently is taken to mean that you have more trouble with it than people who don't recognise that it is a significant problem.

I've worked in distributed development in distributed development for a good deal, and that includes distributed development within single companies, distributed development involving many companies, distributed development involvingmany teams in inductry and in academia, a for about 18 of my 40 plus years in computing/IT, and I've seen all three (hub/spoke, peer-peer, and ad hoc) ways of working. Some of the projects have succeeded, some have failed, some succeeded but very late or with reduced functionality. The model which I hate is what I call the prima-donna model - it's something which is envisaged as a peer-peer model but each peer decides it is the hub and the rest are the spokes., and guarantees complete failure. The best results I've seen have been from the ad hoc model. The trouble with pure peer to peer is twofold: first, generally speaking someone has to own the requirements - you can't sensibly outsource your requirement setting; second, it can deteriorate into the prima donna model.. The trouble with hub-spoke is that the team that owns the requirements gets to control things outside its field of competence - a complete nightmare if there are any natural prima-donnas on that team..