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%
Open source software has a better success rate than 70%? I suspect it's much lower. Plus you only have to code something if you want to. It's really apples and oranges.
However having worked remote for 2 years I'd say
Establish clear communication guidelines - like what hours someone should be available in IM for instance communication
Make sure your team has tools to virtual whiteboard
I finally gave up on it when most my team was 6 or more hours off me and no one wanted to joint design. Quite happy to be back face to face most of the time.
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.
Keep the size of commits reasonable in order to give those leading a feature, or function a change to check the code. Many OSS projects appear to use hackathons for larger commits requiring lots of communication.
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.
The issue is communication.
With remote workers agile startes to fail becuase of the lack of meaningful face time. Waterfall slips on time delievery. Floss is combo of them both so same hit.
Documentation is heavily required. We are talking fine details. Saying "Need an AR by 3pm" will not work. The meaning of A/R report is different every where! So devil is in the details!
Most important is talk talk talk. Have a meaningful discusion on what is date - yeah a date! Like it is Jan 31, 2016. You add amonth to date, what date do you get back? Add two months? What is being of quarter? ... This is imporatant to get the basics correct! Same goes for names, addresses, time, ...
Last oversee culture issues hit hard. Far East, it is common to always agree and build consenous. So on the phone and they say "yes", it could just as well mean "no", becuase consenous has been met. Also watch time lines, one was under bid for time by a factor of 10. They quoted the time to do the build (what was asked) then took 9 times that to test everything (their corporate policy). We saw the stretch with in a month showing the missed mark. We asked and talked and asked and talked... their estimate remained the same. Finally got light of problem actual problem, after taking low level developer that I ask to document the proces he was doing.
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.
1. FLOSS development is done for the love of it, not for the payout and benefits
2. As was stated, FLOSS members can easily be dismissed from the dev group if their code sucks, they suck or other reasons; paid employees cannot unless they have well worded contracts and the company has draconian lawyers
3. FLOSS development is usually not on a fixed timeline or using some acronym-of-the-month development paradigm, e.g., Agile, SCRUM, Waterfall, etc. so releases happen when releases happen. Not saying there aren't goals, but people don't get fired if a release slips a few months/years
4. Communication is often more asynchronous and not as immediate with FLOSS (unless severe bug, looking at you OpenSSH!) Things move at a much slower pace than within a corporate, results driven environment
There are others that I am sure folks will bring up, but those are the major apples-to-oranges issues when comparing FLOSS dev groups to corporate ones. It's a different world when someone else's money and time are involved in developing something. A lot more risk and responsibility involved in the corporate environment when your life literally depends on the paycheck and benefits from your work.
Isn't it ironic that a great percentage of the programming that occurs today is for using the Internet to enable online commerce, collaboration, and business? And yet the Agile community (of which I am a member, and believe in Agile - although not ever single idea or practice) shuns distributed teams - the very technology that we build.
http://valuedrivenit.blogspot.com/2013/11/are-agilists-turning-their-backs-on.html
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.
God said to Noah, there's gonna be a floody-floody. Rain came down, it started to get muddy, muddy. Get those animals, out of the arky-arky
If those 2 days are really productive, that's one thing. But if it's just people bullshitting, forget it - it's a waste.
Traveling sucks - and that's if the company allows you to travel on their time. Meaning, drive to the airport at 1:00PM and get at your destination by dinner.
But what I usually have to go through, is the plane leaves at 7PM so I have to drive in rush hour traffic from work. Then by the time I'm in bed, it's Midnight or later.
The next morning, I'm wiped and can hardly function.
Then repeat on the way back.
Oh, and I better be in by 8AM the next day.
And that's staying in one time zone! Going across country was just a nightmare.
I quit that job as soon as I could.
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.
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.
What kind of meetings do you go to? Most my meetings have more points on the agenda than we'll conclude on and the remaining discussions are tabled to the next meeting because some of the members have to attend other meetings, the room is booked for a new meeting or people need to leave for the day. Status meetings can be the exception when there's a fixed time slot set off every week and not much is happening, but rarely those where we plan the schedule and resources, discuss the architecture and design, solve implementation issues and so on. It always could be fine tuned further, the question is if it's good enough that we can move on or if we have to resume the discussion later.
Live today, because you never know what tomorrow brings
Current has been up too long
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.
When someone checks IDE configuration files or broken code into the repository, make sure you publicly and thoroughly humiliate them for the whole team to see. Seriously. I can't tell you how many hours have been lost on projects both corporate/internal and distributed because of crap like that.
If someone is too lazy to even make sure their code builds before checking it in, they deserve to be humiliated as the unprofessional hacks that they are.
I do not fail; I succeed at finding out what does not work.
at cleaning teeth
No, seriously: can you cite a study with a solid methodology to demonstrate that less than 70% of FLOSS projects succeed? I ask because there's a lot of orphaned projects out there that most people have never heard about and that are effectively dead, their code either unused or in desperate need of replacement (because it's not being maintained).
Finding God in a Dog
s/succeed/fail. Original should read:
Finding God in a Dog
Lucky you: you haven't run into those types of meetings. Hang out with business types more often, and you will.
Also, here's an idea for you, since you're already making up an agenda. Send your agenda to everyone the day before the meeting, have an email discussion on those points, and see how many of those items you can resolve before the meeting. Once you get the hang of it, I'll bet you'll be able to get through all of them, and you can save the meeting time for more important things.
"First they came for the slanderers and i said nothing."
small development team (10+ people)
I've been working in the technology field for over 15 years, mostly huge companies, some small ones, and my current team has 10 people and it is by far the largest team I have ever worked on - and the least capable.
How to do it so not to need to see a dentist?
Yahoo//
Be a bunch of paranoid nancys and don't take submissions from the remote team without a month delay at least. Then revert it a month later without any explaination. Then, after falling behind on a one year project by two years, get everyone fired and the entire division shut down. It seemed to work for them.
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.
Apropos of nothing, when will Firefox be done?
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.
I've been involved in a number of open-source projects, mainly at apache.org. The common features of successful projects appear to be:
* code reviews - have a couple of senior developers allocate significant time to reviewing code. Some projects have a "review before merge" policy, some a "review after merge"; I would suggest _before_ if possible, but choosing a decent version-control-system (eg Git) makes this easier. This review process is also the main _communication_ mechanism; you can have all the meetings you like but people still misunderstand things, or don't listen. Having feedback from a reviewer really brings people to understand the right way to do things.
* good test coverage - with a distributed team there is less ability to just pop over and ask the author of some code what they intended. Good unit tests can at least partially cover for this lack; it's clearer how things were intended to work, and hopefully misunderstandings will trigger test failures.
* and really try to avoid 1:1 communication where possible, ie communicate via open lists, wikis, etc rather than direct emails.
I disagree on point 5, over here we have some co-workers that seem to enjoy extending any meeting that should have lasted 30 minutes to 2h or more. Then the last 75% of the meeting are a waste.
Whenever I'm in one of those meeting, I make sure to have "something important" planned within one hour of its starting time.
I've almost never seen a 1-hour meeting that was productive for the full hour. At least a few of the people attending will be wasting their time being there for 1 hour.
If someone skilled is leading the meeting, it will usually be over in less than that our and still get the relevant points discussed. If not, it degenerates in discussing loads of things that are irrelevant because the right people aren't available, irrelevant because it's not something that can or should be decided on now, etc. etc. If you want to discuss that kind of thing without a clear agenda and things to solve and think it needs to be face-to-face, meet over dinnner or something, then people are at least in a better mood.
It's about motivated, interested team members, now fashionably referred to as "engaged", and this is the case whether they are remote or in-office. A highly motivated, capable remote worker is much better than an unmotivated, not-so-capable desk jockey. So -called "teams" are in reality groups of specialists with good communication and good coordination and good remuneration.
I hate working in offices, particularly cubicle or open plan with no quiet office of my own. Marissa Meyer can **** her **** with a ** *****. I am far more productive online at home, provided I have good interesting work to do and good people to work with, even if they are the other side of the world, it doesn't matter.
Good tools: we find Slack to be very useful in our distributed teams, keeping people in touch and propagating the occasional bonding joke (which builds relationships), though it can be distracting. Email still has its place. Skype or Google Hangouts for the occasional face to face but mostly an audio call will do, and rarely at that. Minimise meetings but insist on at least one manager-soldier call, preferably one-to-one, every few weeks.
Thus spake the Master Programmer:
"Let the programmers be many and the managers few -- then all will be productive."
I suspect that for every distributed OSS project that succeeds there are many that fail. You see the successful projects and the failed ones tend to slip back into obscurity. You can possibly learn something from the ones that succeed, but it shouldn't be 'OSS projects successfully manage distributed teams all the time.' I think that the majority of such projects actually fail. However, reaching out for advice or examples from the ones that actually work might be helpful. You should find folks on Slashdot who actually are involved with successful OSS projects. Maybe they will have something worthwhile to say.
Isn't it ironic that a great percentage of the programming that occurs today is for using the Internet to enable online commerce, collaboration, and business? And yet the Agile community (of which I am a member, and believe in Agile - although not ever single idea or practice) shuns distributed teams - the very technology that we build.
http://valuedrivenit.blogspot.com/2013/11/are-agilists-turning-their-backs-on.html
There is absolutely NO reason why software teams have to be "face to face" or even in the same hemisphere let alone country. It's ridiculous. Everyone simply has to know they are supposed to be doing and then produce it. Even when people are in the same office, a technical matter is most likely to be resolved via email or Slack (and then the reasoning process is documented and everyone can re-read it). So why do they need to be in the same office, sending emails to the guy in the next farm cubicle? Ridiculous, and all part of keeping workers chained to a desk and miserable.
What about some decent project management around whatever toolset you decide to use?
Whenever a project becomes complex (i.e. many interfaces) the need for competent project management becomes greater, the tools don't make the project successful, its the addition of quality assurance, methods and well defined procedures that make the overall system more likely to succeed, imho.
It should say: "You shouldn't have different pipelines depending on location." ... of course. Sorry for the typo.
We suffer more in our imagination than in reality. - Seneca
Garcinia cambogia capsules supports weight management. Garcinia Cambogia are manufactured in Newzealand.
How do you know FLOSS projects don't suffer a 70% failure rate too. Or perhaps even worse.
FLOSS projects typically don't have deadlines unless they get really popular, way after they passed the "success" treshold.
If a FLOSS project that hasn't had updates for years a failure or a success, even though it's fully functional?
Projects that don't meet budgets, deadlines or functional criteria are considered failed. Most FLOSS projects don't have any of these unless they already had some level of success. Most FLOSS projects die well before reaching that level, though.
Judging by my own subjective standards of failure; most projects on Github and Sourceforge are failures. They have no code, cannot compile or have showstopper bugs and no recently activity that could remedy these problems.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
What is with all the nay-saying?
- Set clear expectations. Develop good documentation around everything you do, not just around code. Develop clear communication guidelines. Don't be afraid to ask for clarification.
- Call a turd a turd: file thorough defects for anything that does not meet expectations. Happy path quoting at low prices gets sub-par developer jobs. However, they do not keep them once true cost is calculated, when true cost is actually calculated. This goes for any team, not just the remote team.
- If it is the situation of an remote development team that is just programmers as opposed to an engineering office, then provide very clearly documented designs and allow time for design review and code review.
To summarize:
don't assume. write it down. come to an understanding. don't make excuses.
It'll make everyone involved happier in the long run
-dam
There is absolutely NO reason why software teams have to be "face to face" or even in the same hemisphere let alone country.
Not the programmers, no. But a sw project is much more than programmers. You may need extensive communication with users/testers, to get a product that is actually useful. The architects (and the programmers) must understand how the sw will be used. Otherwise, they cannot make something really good.
I don't think FLOSS project have a better success rate. Probably even worse.
The good thing about the FLOSS fork/merge/die paradigm is that the possibility of failure is integrated in the developpement workflow.
If there is one thing to take froml FLOSS, this might be it.
How many open source efforts do you know of where there is only one version of the software? Forks are common and even encouraged! I name mysql because that's what's coming to mind right now, but there are several forks of it: drizzle, mariadb, Percona. I realize that the project has a semi-commercial license, but anyway, you get the idea. Projects fork all the time. Hell, there's a "fork" button right on github to make the process easier!
In the commercial software world, you don't get to just hit the "fork" button.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Somehow, the vast FLOSS projects out there manage to produce working software without sales, marketing, product experts, managers, executives, VPs or any of those other people who don't actually CONTRIBUTE to writing or testing the code.
10 people working on a project is pretty large for most companies.
I use a number of products like that which really don't get much in the way of updates. Even so, at least your project has a maintainer that probably answers the very infrequent question and obviously addresses any bug reports in some fashion. Lots and lots of sourceforge projects never ever release code. I expect many die at the "I had an idea" stage, but others just never really sort out the organizational or "marketing" issues (IE getting people interested and trying the code so that something grows).
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Open-Source software has a number of irreconcilable differences from closed-source software that makes comparison tricky:
- Ownership
- Rejection of low-quality code
- No deadlines
A similarity:
There are more open-source libraries on GitHub in Javascript than any other language, and quite a bit of consumption of them. Most are built & maintained by one person. Lots of components are used to build an advanced website, but each is fairly replaceable.
My closed-source employer follows a similar process with each developer exclusively maintaining one or more tiny programs. Some of those were designed poorly to meet a schedule (by people who were let go). Now others (me) are creating replacement programs. Since each program does effectively very little, and it's well-documented for integration purposes, it's quite easy to replace entire programs outright that contain trouble. This gives us the same language freedom that open-source enjoys.
Further, it's a revolving door. Any program that's sufficiently devoid of "company secrets" is free to be open-sourced. This makes the company "dev-community focused" which helps hiring & retention.
Science & open-source build trust from peer review. Learn systems you can trust.