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%
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
I'd agree except for the "without lengthy explanations". There's also a pretty big distinction between "sugar coating" and using a bit of diplomacy. Telling someone their code sucks with little explanation both does nothing to really help them and may just create bad feelings and frustration. Why create unnecessary tension in the workplace if you don't have to?
I tend to prefer taking more of a mentor position with programmers on my team if I feel their work needs improvement. This includes not just telling someone how to do something, but listening and finding out *why* they chose to write code the way they did. I think this effort will ultimately make them more productive in the long run, rather than just shuffling them off to another project or another company. If they're not responsive to those efforts over time, either deliberately or because of a lack of talent, then at that point get rid of them or transfer them to a position / place where they're more suited.
This is a bit different than in the FLOSS world, where you really wouldn't have the time or inclination to mentor everyone who submitted code. It's probably more appropriate to be direct and concise in those cases, as otherwise you'd have all your time sucked away.
Irony: Agile development has too much intertia to be abandoned now.
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.