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.
Use IRC. Typing skill is not optional.
FLOSS can simply reject code that's not up to standard. If someone on your team turns in shitty code you can't always just not use it.
Who told you FLOSS doesn't have those problems? they lied. many FLOSS projects fall apart because of the "virtual teams" of people with different goals and aspirations. I would not be surprised if the failure rate is even higher than 70%
I think a big difference is in how you can just 'fire' people casually in FLOSS. You don't have to accept people's pull request. You can tell them their code sucks, w/o sugar coating it. There's also non-monetary incentives that drives FLOSS that you'll have a hard time duplicating. That said, may be make it clear to your boss that you should be given the power to reject bad code w/o lengthy explanation. The ability to change team members easily if need be. Also, may be the ability to say more about a project when posting job positions, and not just the generic, "Over x years of experience in y". The linux kernel is a good example. Also, you must have people who knows git well.
Here's what a lot of teams need to learn:
A lot of meetings can be done more efficiently and effectively by email. Here are ways you can tell:
1) If half the people in the meeting are checking devices, not listening, the meeting should have been done by email.
2) If everyone sits down at the 'stand up' most of that meeting should have been done by email.
3) If people are standing around with blank looks on their face, the meeting is probably a waste.
4) If the meeting is in the morning, and after lunch no one can remember what happened, the meeting is a waste.
5) If the meeting ends exactly one hour after it starts, then it's a time filler. Finish the meeting when everything is accomplished, not when the time is up.
6) If it's not clear what needs to be accomplished in the meeting, it's a waste of a meeting and should be cancelled.
Someone above suggested that the meeting could be done over IRC instead of email. That is also a perfectly acceptable alternative.
"First they came for the slanderers and i said nothing."
All you probably NOTICE are the more successful FLOSS projects. For each one of those, there are 100, possibly even 1000 that languish, maybe make a release or two, and then lie in their shallow graves on sourceforge for the next 10 years.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Gimme a break. One talking head wants to publish a "study" and suddenly it's canon? What does "failure" of a virtual team even mean? Probably, less money for the talking head.
Virtual-enabled teams, in my own experience, may not result in any massive, curve-jumping gains suitable for a click-baity headline, but I do think they are at least as good, and decisively better in a few key ways, as traditional, rigidly office-bound teams. They are cheaper facilities-wise, and result in vastly higher morale and loyalty among the employees who are able to work from home. They do not result in goofing off or falloff of productivity, except among employees who were worthless anyway.
Ultimately, virtual-enabled teams amplify whatever is good or bad about the leadership and quality of the hires. Good hires become great hires because they don't waste their work house stuck in ever-increasing traffic. Do-nothing managers become disaster managers. And the morons who represent the failure of the hiring process will spend their days at the beach and be discovered far earlier than they would have.
Virtualization is a Great Thing. But it highlights how the current state of management and hiring in software is a Terrible Thing. Don't believe the haters.
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.
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.
IMO, tools are a secondary problem. Many FLOSS project succeed with just e-mail and a distributed version control system (even plain old CVS). Motivation if the key point of FLOSS: people really want their contribution to get upstream, and that push them to make a lot of efforts. This may be difficult to reproduce with employed developers that may not care much about the project.
Someone paid to do a job they dislike, with people they don't know, are likely to do only as good a job as they need to get paid. When they are very far away, that could be very little at all.
Someone volunteering to do a job they enjoy with remote people who share the same hobby and ideals? Unsurprisingly, they tend to do a better job, despite the lower accountability you have when working remotely.
This isn't rocket science.
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
Successful FLOSS projects are often compartmentalized in a way that allows developers to complete much of the work independently. If your code is highly interdependent, you'll need more high quality communication between team members and that is more difficult for virtual teams. Some problems, and some code bases, simply do not distribute well. A FLOSS project that grows up distributed is more likely to be successful than a commercial project developed by a collocated team that then is handed off to a distributed team.
Initially, the code structure follows the team communication structure. Once this is in place, the team communication is constrained by the code structure. When making changes to one, plan to make changes to the other.
From good, working FOSS projects you can learn just about anything. As for the distributed software development: One thing people can learn from FOSS is versioning. Seriously. Quite a few teams I've met in RL can't and don't/didn't version, with FOSS it's mandatory. A very important aspect is that FOSS teams version just about everything, including docs and assets. Very important.
Another thing distributed teams can learn from successful FOSS projects is not to drown in tooling-bloat. Most tools in FOSS are tried and true and have a track record of decades. IRC, simple IDE/compile setups, tried and true working environments (f.e. LAMP stack), a bug/issue tracker that does the job and maybe a web-forum. I like to use the Google suite for my projects, but that's mostly for FOSS stuff, so it doesn't matter to me that much what Google is reading along. YMMV.
One thing that I would recommend when doing distributed development is, that you should set up your entire environment and pipeline, so that it is ready for distributed devlopment. You should have different pipelines depending on location. The overall process of versioning, tracking, compiling and deployment should be the same for everyone. The difficult part isn't getting the externals to do their thing but to get the locals to switch to the new, optimsed processes.
Another thing good (FOSS) projects have in common is a clear vision and good gouvernance. The stakeholders and PMs of FOSS projects actually have their agency behind the thing. If they don't, they quickly drop out or the project simply never gets off the ground. ... That's a huge upside to FOSS btw. In paid development, you get idiots dragging along for years, simply because there's a paycheck involved. Very painful. I've seen that a lot of that.
We suffer more in our imagination than in reality. - Seneca
Parent makes a good point but misses another. We need some baserates indeed to make a reasonable assertion about the damage or benefits to virtualizing teams. But really it doesn't quite matter how you measure failure, as long as you use equal measures on both normal and virtual teams. Of course to get a complete picture different types of failure should be considered, but for each particular measure the comparison is still valuable.