Slashdot Mirror
Ask Slashdot: What Can Distributed Software Development Teams Learn From FLOSS?
An anonymous reader writes: As a long time free software proponent and leader of a small development team (10+ people) within a mid-sized company, I always try to incorporate my experiences from both worlds. Lately I was confronted with the need to accept new team members from abroad working on the same codebase and I expect to have even more telecommuting people on my team in the future (even though research suggests the failure rate of virtual teams could be as high as 70%). On the other hand, FLOSS does not seem to suffer from that problem, despite being developed in a distributed manner more often than not. What can corporations and managers learn from FLOSS to make their distributed teams more successful? Consequently, what FLOSS tools, methods, rules, and policies can and should be incorporated into the software development process within a company more often? I'm interested in hearing what you think, especially regarding technical issues like source code ownership and revision control systems, but also ways of communication, dealing with cultural differences, etc.
An AC, very close to first post, and it is actually spot on!
Unless you can get management to sign on to a mentality of "it will be done when it's right" rather than "it will be done on Thursday" you have no hope of achieving FLOSS levels of success. I'm not saying you shouldn't try your best, merely that you should be aware of your limitations and from whence they come up front.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Many years a go I was coordinating a group of developers that was somewhat larger than yours and possibly even more distributed. E-mail and phone conferences were fine, but they were no substitute for face-to-face communication. At some point I just decided that we all needed to get together for a 2-day meeting every month, which meant everyone else had to fly in, except for those in Asia, who joined by videoconference in spite of ridiculous time zone differences. No objections from upper management. It definitely helped (and later learned that people regretted when I stopped holding the meetings.) The key is to make sure you work in a place where it is a non-stop flight for everyone else.
At the moment I am working on a project where the center of activity is two time zones away. Coming up on a review, I realized that there was a big disconnect in how the people in charge thought my part of the project would work - this in spite of our having even more advanced online collaborative tools to communicate. On my own initiative, I flew out to where the rest of the project is located. It was for 2 days, and it was extremely productive - indeed, essential.
There always seems to be a mandate in organizations that people travel too much, and it needs to be cut back. I look at it the opposite - people don't travel enough.
Managers love meetings. For some of them, it means that they get to lord power over their subordinates just so those people know who the boss is.
Most of my meetings were intended for blame-placing. I was doing much scheduling in my previous job, but the software that had been written didn't function properly. Explain this in meetings, provide parameters for the developer to fix it, leave meeting knowing I'd contributed to the success of the business.
About 30 minutes after the meeting concluded, I would receive an email explaining how the problems with the scheduling/website/whatever were my responsibility to deal with, even though the basic functionality of the tools was compromised (scheduled items could not have punctutation as the code was not properly escaped, other items would be trapped in transit, but these were my problems to deal with because it was my job to ensure everything was correct and professionally written).
It turned out that what was really happening was that they gave me a chance to explain what was going on, and then after my part of the meeting was over, the manager and his pet IT boys would blame me for not doing it correctly.
70% failure rate really doesn't seem high at all compared to various failure rate studies I have read. Here is a study which shows 68% of all IT projects fail, so I guess an extra 2% for distributed teams isn't too bad.
One problem of these failure rate studies is how you measure failure. Most of them lump into one group all projects which exceed their budget, fail to fulfill the full project scope, or other common scenarios. It may seem reasonable at first, but is a one year project that goes live in thirteen months really a failure? Or if the management team carefully removes some features from the scope so it doesn't go over budget, is that still a failure? Sometime yes and sometimes no on both accounts.
The most important thing to remember is these studies are being marketed to companies who sell requirements gathering tools and consulting services, so they should be taken with a grain of salt. For instance, the company who did the study I linked to above has the following paragraph at the top of its mission. I hope it puts into perspective any doom and gloom predictions made about how likely a project is to fail if you don't use proper enterprise-wide requirements solutions.
IAG provides world-class enterprise-wide requirements solutions to help clients achieve their business and software development objectives. We champion the position that: accurate and clear definition of true requirements is a key success factor in achieving superior IT delivery results.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
Open Source projects that are successful are so because they have documented procedures and follow them. They also document their communication in mail list or otherwise, but take the attitude that if the communication didn't happen (or wasn't later summarized) on official channels, it didn't happen at all. Unsurprisingly, these are the things that might other projects successful. I'd suggest making sure you have a good change request system, a good change control system, a method for official communication, documented processes, and zero tolerance for anyone trying to skip process.
The problem is that in FLOSS, rejecting code may bruise somebody's ego, but that is it. In commercial development a whole slew of contractual issues come in. The basic difference is that dependent on contract, the bad code still has to be paid for and if not (fixed-price contract), the rejection arguments need to be solid.
This can be really difficult, and I have been on both sides of the issue. Some times the only way to deal with this is to accept the bad code and have somebody else fix it. Sometimes that would be the only real option, but budget does not allow it. And forget about legal steps: The legal system is so glacially slow that a small shop cannot wait for it. In addition, it is utterly incompetent, when technology is concerned, so even with a very clear case of non-performance by your supplier, you can still lose or only get token compensation.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.