Ask Slashdot: What Can Distributed Software Development Teams Learn From FLOSS? 133
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.
Skype is for children. (Score:3, Insightful)
Use IRC. Typing skill is not optional.
Re:Skype is for children. (Score:5, Insightful)
I use IRC and chat pretty extensively at work, but some conversations just work better over voice.
Not everything's a nail. Just sayin'.
Re: (Score:1)
What types of conversations are those?
For most work-related conversations, chat provides (or at least, can provide) unobtrusive, asynchronous communication along with an electronic record. Individuals have the opportunity to read what they wrote and make sure it is what they want to say before sending it to chat. You don't have to deal with heavy accents or speech impediments. Additionally, it's much more difficult for one person to monopolize a conversation in a chat room than it is in a conference room
Re: (Score:2, Troll)
Conversations that human beings and coworkers have. I understand that an introverted, socially-awkward basement-dweller such as yourself may prefer not to embarrass themselves by speaking to others, but it's a necessary skill if one wishes to succeed in any number of endeavours.
Re: (Score:2)
Human language is, by it's own nature, hopelessly ambiguous. We use technical terms and jargon to eliminate as much ambiguity as possible, but completely concrete communication is not achievable. With plain text, you lack the voice inflections and tone. With a phone, you lack body language can't get direct listener feedback. Being in person enhances communication in a very real way. About the only thing that's nicer in text is a code snippet, but code snippets on their own are not exactly crystal clear
Re: (Score:2)
Meh. I've been working remotely for 17 years. Video call is good enough versus coming into the office, particularly for one on one conversations. Chain of emails or in person are not the only options.
At this point we can communicate via multi person video, voice, shared document editing, shared whiteboards, chat, etc. The real challenge IMHO is getting people to embrace these new-ish tools rather than being stuck in, "the way we've always done things".
I've never understood why people seem to feel that conne
You Can't Fix It (Score:4, Insightful)
Re: (Score:2, Insightful)
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.
Why not? If they're not worried about quality of code why not just outsource the entire project to some random company whose "proposals" fill their email spam filters?
Re: (Score:2)
Re: (Score:2)
Dude, I know we work with binary quite a bit, but equating a lack of 100% veto power to complete indifference toward quality of code is taking "all or nothing" a bit too far! (Sorry; I couldn't resist the pun)
Dud - why reply to my post? Don't you understand sarcasm/satire/irony - or do you just not understand how to reply to posts? FLOSS and closed source can, and should reject crap code. Just because I pay someone doesn't mean I can't reject their code - at least where I live (consistent crap code == termination, either for crap coders or projects that deploy crap code/miss deadlines).
Re: (Score:2)
Re:You Can't Fix It (Score:4, Interesting)
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.
Re: (Score:1)
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.
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
Re: (Score:1)
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.
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
You'll have a hard time putting something that subjective into a contract, you could change your mind about the project half way through and just reject all their code. You could also look over all their code, reject it for an arbitrary reason and then write your own implementation using all their best ideas.
The only way to enforce it would be to have objective criteria such as having the requirements completely specified in fine detail, QA tests to cover all situations and required coding conventions writt
Re: (Score:2)
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.
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
You'll have a hard time putting something that subjective into a contract, you could change your mind about the project half way through and just reject all their code.
Yes - it happens all the time (changing projects, rejecting code and terminating employment). We don't need contracts that specify the quality of the code - but they do exist e.g. secure code standards. Don't know what planet you live on where that doesn't happen (Planet Couch?).
Re: (Score:1)
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.
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
You'll have a hard time putting something that subjective into a contract, you could change your mind about the project half way through and just reject all their code.
Yes - it happens all the time (changing projects, rejecting code and terminating employment). We don't need contracts that specify the quality of the code - but they do exist e.g. secure code standards.
OK. Now I'm confused:
So write the contract accordingly, then. Such as "Code will be rejected or accepted based on merit. When the product ships, payment only for code that got in."
We don't need contracts that specify the quality of the code
If you're saying that at some point during the contract you realise it's not working out, pay for the time spent and terminate early then that's fine. If you're saying that you'll pay based on some evaluation of the end product then the criteria for success need to be very clearly defined at the outset so that the contractor can assess the risk of failure and decide whether to take the contract.
Don't know what planet you live on where that doesn't happen (Planet Couch?).
I don't have any direct experience, I've just chatted to people who are contractors on other
Re: (Score:2)
Yes - it happens all the time (changing projects, rejecting code and terminating employment). We don't need contracts that specify the quality of the code - but they do exist e.g. secure code standards.
OK. Now I'm confused:
:)
It's both. Most commonly coders are either employees or contractors - they can be terminated for a number of reasons. Generally it's simplest to simply say "you are surplus to requirements". Less often coders (or companies) are contracted to produce code to a standard (i.e. named security standards) - if the code is not up to standard it's a simple breach of contract. The usual process (best practise) when dismissing an employee or contractor is to give them the required notice but escort them out the doo
Re: (Score:2)
Not sure anyone would accept that for a contract unless they were desperate. Yes, their work is shite, but the outsourcer did have to pay someone to write it, and those people might work for peanuts, but they aren't working on spec.
The open source projects succeed in that regard because they really have no direct pressure to release anything. If the next feature comes out, it comes out. If *you* need that new feature, then you have a paid development team work on that feature and you beat *them* into com
Re: (Score:2)
And the reason anyone writing code for you would accept your entirely arbitrary deal where you can reject everything they've done without payment at your own discretion would be...?
Re: (Score:2)
And only a terminally stupid supplier would sign that one.
Re: (Score:2)
You are right in your assessment, but there should be a solution for that.
Time and materials contracts can take care of the issues you are talking about. You can reject a pull request, but still pay for the hours.
It's a lot cheaper to pay for the hours than to fight over them. If it's an employee, help them get better, refine your specs, or maybe move them or replace them, if they are not fit for _that_ project. If it's a contractor, change contractors if they are bad.
If you are contracting software develop
Re: (Score:2)
While I agree on most of what you say, all these solutions only work with a realistic, sensible budget that takes unexpected cost and the benefit of a quality-product into account. That is usually missing these days, as the bean-counters just do not understand that "1 developer day" is not a standardized product at all and can vary in productivity by a factor of 1000x .... -1000x from the average. (Yes, that is a minus and I am not sure I am exaggerating.)
Example: If I make a fixed-price offer, I do the bes
Re: (Score:2)
The problem is that in FLOSS, rejecting code may bruise somebody's ego, but that is it.
Wrong. It's wastes valuable time. And the only difference between commercial and FLOSS software development is that FLOSS doesn't always pay coders - both styles (closed and open) cost time (time == money), both can produce crap code and miss deadlines, and both can have butt-hurt contributors whose code was rejected. That's why we pay them to piss off and suspend their access rights when we've had enough of their crap code - at least in sane, consistently profitable companies doing closed source software d
Re: (Score:2)
Apparently you have a reading comprehension issue. Obviously I was _not_ talking about the cost to the contributor.
Re: (Score:2)
Apparently you have a reading comprehension issue. Obviously I was _not_ talking about the cost to the contributor.
Neither was I - try re-reading, though you might need to rest your lips a bit first.
Re: (Score:2)
You sound much like a clueless MBA, i.e. one not worth listening to.
Re: (Score:2)
If they are paied employees, then having them write code that is barely ever accepted, is a waste of money.
Open source projects you have unpaied sources, so rejecting code isn't any cost.
Trying something like paying only for accepted code may work... However you will need to pay them more to account for the higher risk working for you.
Re: (Score:2)
If they are paied employees, then having them write code that is barely ever accepted, is a waste of money. Open source projects you have unpaied sources, so rejecting code isn't any cost. Trying something like paying only for accepted code may work... However you will need to pay them more to account for the higher risk working for you.
Rubbish. I don't know everything about software development - but I have spent thirty odd years doing it, both FLOSS and closed source, and your opinion as contrary to most of my experience. Sure there are corner cases where you're told to keep Dumbo on because the major shareholder is their parent - they're the companies you don't want to work for and are no more useful as a guide than your opinions about bubonic plague and automobiles [slashdot.org] or "other countries" where people smoke one or two cigarettes a day [slashdot.org] (no
Re:You Can't Fix It (Score:5, Interesting)
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.
Re: (Score:3)
Re:You Can't Fix It (Score:5, Insightful)
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"
A mentality of "it will be done when it's right" is almost as foolish as "it will be done on Thursday." Software will never be "right". Quality software requires people who are able to perform proper risk management during all stages of development. I will not prevent my team from moving from discovery to design just because I think there may be requirements we are missing (hint: there always will be). We will move on when I believe the risks of moving on are less than the risks of not moving on.
My current backlog is full of feature requests, suggestions for more clear UIs, bug fix requests, etc. If I waited for my backlog to be clear before each release, my boss would still be waiting for our alpha version. Part of my job is also making business users comfortable with my change management decisions. If my bosses implore me to finish testing too early or slack on documentation, it is largely my fault for not convincing them it is a bad idea.
Re: (Score:3)
A mentality of "it will be done when it's right" is almost as foolish as "it will be done on Thursday." Software will never be "right".
I don't think it's an unrealistic standard of perfection, the point is that it's done when the code does what it's supposed to do. It won't be done because the boss sets a deadline or marketing wants it or the bean counters want to hit the Christmas sales. Or even because the developer wants it to. They act like the code is in the chain of command, they tell the developer what to do and the developer tells the computer what to do so if they say Thursday it will be done.
Except the computer doesn't give a dam
Re:You Can't Fix It (Score:4, Insightful)
Honestly I feel your heart is in the right place, and your level of principles will produce far better products than those who care little for software quality. But your statements really don't reflect those of someone who has ever actually been in charge of large software projects. Either that or you are one who constantly feels things would have been done better if your bosses simply got out of your way. I could very well be wrong, but I doubt it. My guess would be you are a skilled senior level developer who likes to stay on the technical side of things, but that is mostly just a wild guess.
I don't think it's an unrealistic standard of perfection, the point is that it's done when the code does what it's supposed to do.
Code is not predestined to do anything. It does what humans have it do, either consciously or accidentally. If I say to release a product (with my bosses' approval), then the software is doing what it is supposed to do, which is go into production.
It won't be done because the boss sets a deadline or marketing wants it or the bean counters want to hit the Christmas sales.
This is why I don't feel you are speaking from experience. The fact is getting those Christmas sales are probably far more important than your viewpoints on perfection. And sometimes those deadlines are there for a reason. Developers are not tasked with creating some shining example of what perfect code can be, they are tasked with making a return on investment. I have a project right now which is due at the end of April because it really has to be done by the end of April. The scope of the project has changed frequently as planning and development has taken place to ensure this April 30th deadline will be hit. And it will be hit. It will be hit without 80 hour weeks; it will be hit because proper project management techniques were used throughout the project. And part of those proper project management techniques are respecting that the deadline is there for a reason and there are very few requested features that are more important than this deadline.
They act like the code is in the chain of command, they tell the developer what to do and the developer tells the computer what to do so if they say Thursday it will be done.
Honestly, writing code is the least important and easiest job of a developer. We learn how to write code in the first few years of our career; probably in school. A quality software developer's career is spent learning the more important tasks of software engineering. This includes your senior developers knowing what can be done by Thursday. You can hit deadlines without just pretending your code is working. You hit deadlines by understanding the progress of the project and understanding the priority of its features at all times. This isn't some hobby or college assignment. There may be millions of dollars on the line, and thousands of employees or customers waiting.
I have worked in situations where some features were more important than the project's success. In safety critical situations there are times where you would rather have an entire project scrapped than product an un-safe product. Obtaining FDA approval, for instance, is the type of requirement which must be fulfilled. But these situations are rare; in most software development almost all features can have their priority level be put up for review.
Yes, I know that for planning purposes you have to make some kind of educated guess but I can only estimate what I know needs to be done, not the "unknown unknowns" that can throw your estimates off by an order of magnitude or simply make it unfeasible. This is particularly - but not only - true when you're working with third party software and libraries. I say I have a worst-case estimate but really that's probably the 95th percentile, there's no hard limit where you can guarantee it'll work.
These are all very real concerns for real world pr
Re: (Score:2)
Either that or you are one who constantly feels things would have been done better if your bosses simply got out of your way. (...) This is why I don't feel you are speaking from experience. The fact is getting those Christmas sales are probably far more important than your viewpoints on perfection. And sometimes those deadlines are there for a reason. Developers are not tasked with creating some shining example of what perfect code can be, they are tasked with making a return on investment.
No, actually there's where I'd like the manager or business owner to get in the way and do his job of figuring out what's most important and if necessary make those hard calls between schedule, quality and cost. I've actually worked a lot with project and portfolio management tools and I know those warning lights start blinking but poor managers want to have their cake and eat it too. Like one project I was in once was supposed to last eight weeks, it got three weeks delayed due to a contract problem but th
Re: (Score:2)
(the truth)
All this might be wonderful, but very expensive. I'm not here to tell you how you should do your job, or how other developers should do theirs. but I'm just saying that in my experience, where you have unhappy developers, you might have some unhappy code, and that means the agility of the project to be able to move forwards with new features is in question, as I'd predict new features taking exponentially more time to implement, as it's likely the code if suffering from a lack of separation of concerns.
The warning it there from the developer, but the stakeholders are happy. Case closed, move on... until that change request comes in, and the new developer says it's going to take 10x longer than the estimate! Hence, the "just get it working" approach - which further kicks the can down the road called "technical debt". Sooner or later the company pays for it, and often it's with a complete re-write in a few years!
Well said.
This is indeed a worst case scenario, which unfortunately play out too often. It is most often caused by not having enough developers on the "His side" of the argument. I for instance am a senior level developer who is very involved in the business side of my employer's decisions. This probably comes from my time as a contractor where I have also seen these his side, her side, and the truth arguments play out time and again. A company that does not have enough developer minded people in CTO, VP of
Re: (Score:1)
Management should understand that a feature with bugs is an incomplete delivery.
So there is no such thing as a complete delivery then?
Re: (Score:2)
You only say that due to the limited scope of your vision. You think "it" is "the final product"; I never stated or implied any such thing. Each feature. Each bug fix. Each of these is "it". The bug won't be fixed by Thursday, it will be fixed as quickly as possible while still conforming to security standards and following established process. If that is Thursday, awesome! In fact we hope it will
Re: (Score:3)
You only say that due to the limited scope of your vision. You think "it" is "the final product"; I never stated or implied any such thing. Each feature. Each bug fix. Each of these is "it". The bug won't be fixed by Thursday, it will be fixed as quickly as possible while still conforming to security standards and following established process. If that is Thursday, awesome! In fact we hope it will be Wednesday, but if it isn't right until Saturday then it won't be done until Saturday; period.
There is rarely just one possible solution for any single bug. Change management processes are still involved even at this level of granularity. One solution may be to disable the feature causing the bug. One may be to provide a work around. One may be to put a quick "band-aid" on the code in question, and one may be to find and fix the root cause. If a bug needs to be fixed by Thursday, there are still options even if your developers can't figure out the root causes by then. Once again you weigh the risk o
Re: (Score:2)
I think it is better to say that it gets released when it is complete and tested to totally meet the acceptance criteria set for the feature.
The feature could still be a bad idea itself. The execution could still be flawed, but it fully meets the requirements of what it was expected to do. That's not perfection, that's a testable end result.
Work done against a date will find the acceptance criteria bent, or testing skimped on. If either happens, you run into a buggy or half-baked feature.
I don't know, ho
Re: (Score:3, Insightful)
By which you mean, a landscape littered with abject, abysmal, utter failures and abandoned projects?
Wow, sounds just like closed-source proprietary programming!
You are aware that "FLOSS" is a superset of "Linux, Apache, and Python," and that a vast proportion of FLOSS projects that are started end up in the Sourceforge / Github / Google Code graveyard, too... right?
OP: Want to know how to achieve "success like FLOSS"? Only work on projects that are li
Apropos of nothing... (Score:2)
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?
Re: (Score:2)
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.
"OS" mentality is that it will be done when it's _done_. Not when it's _right_.
And it's tautologically true. You don't need management to change their mentality, only to _accept_ reality, and act accordingly. I know it might be too much to ask for, but it's not too much to ask.
While it does make sense to have a roadmap, release dates for new software are too often wrong. It's a good thing to keep yourself honest about expectations, and drive the development process, so you can get quality stuff, in reasonab
Re: (Score:2)
Sure you can, but it's easier to catch it early and nip it in the bud.
Design reviews. Code reviews. Senior people mentoring junior people. Pair programming if you must. Refactoring. I've had to have juniors I was mentoring go back and rework something that was lame.
It's not like people have never heard of these things right?
FLOSS has the same issues (Score:5, Insightful)
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%
Yup, exactly (Score:5, Insightful)
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.
Re:Yup, exactly (Score:5, Informative)
Very much so. Most FLOSS projects fail or are not very good. The other thing is that successful FLOSS projects often have very small teams of very good and dedicated people. Often you find that things are handled by just one person that really, really knows what they are doing.
Re: (Score:2)
All successful 'open' and 'free' and 'democratic' systems (not just software) are run by a small dedicated old boys club.
Re: (Score:2)
Indeed, they do. The question is are they benevolent or not. If they are benevolent, this model works exceptionally well. (Succession is always a problem, of course.) If not, one distinct advantage of FLOSS is that you usually can ignore the bad projects. I have done that for Gnome, KDE, Firefox as of late, etc., and I could not care less about the mess they are making. Systemd is an example where you cannot easily ignore them and hence the growing opposition to it. But such aberrations are rare and the FLO
Re: (Score:2)
It gets weird. Some FLOSS projects stop because the work is "done". I have such a project myself that does data conversions from one database to another, and several distro download counters say it has quite a few thousand installations worldwide. And yet, I only touch the code when a bug report comes in. Other than that, it's more or less finished. It does what the label says, quickly and reliably. Many people use it in production. There's just not a whole lot that can be done to improve it other than succ
This is true (Score:2)
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).
Exactly! (Score:2)
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
What makes you think (Score:1)
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 bac
Observation (Score:4, Informative)
Re:Observation (Score:4, Insightful)
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.
Re: (Score:2)
More of this, please. Don't demoralize a new programmer who doesn't have the experience to choose well between two similar-sounding options.
It's probably more appropriate to be direct and concise in those cases, as otherwise you'd have all your time sucked away.
Agreed, but with a reminder that "direct and concise" is different from "asshole". You can say "thanks for the patch, but it conflicts with our long-term design goals and we can't accept it" is not the same as "LOL nope".
Reduce commit size (Score:1)
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.
What can on-location software teams learn from OSS (Score:5, Insightful)
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.
Re: (Score:2, Interesting)
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 r
Re: (Score:2)
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, s
Re: (Score:2)
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.
70% "Failure Rate"? (Score:5, Informative)
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.
Re:70% "Failure Rate"? (Score:4, Interesting)
70% failure rate really doesn't seem high at all compared to various failure rate studies I have read. Here [iag.biz] 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.
Baserates (Score:3)
Re: (Score:2)
Well said
Face-to-Face Communication Matters (Score:5, Interesting)
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.
Re: (Score:1)
We've done the opposite - we've let people work from home and/or other offices (interstate and overseas) more and more.
One of our most efficient (and critical, our core development team) is entirely distributed (not a single pair of developers on that team work in the same place), and more efficient now than a year ago when they were all in the office.
I suspect the biggest contributor to success is more to do with morale/happiness/freedom than anything, if you have good staff, and give them the benefit of t
Re: (Score:2)
That's interesting. In retrospect, did you figure out what aspect of the communication was a barrier in the remote case that wasn't a barrier in the in person case (e.g. whiteboards)? Did you have video, shared whiteboards, shared document editing in the remote case?
A "Paper" Trail (Score:2, Interesting)
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
Yet most coding today builds online collab tools (Score:2)
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 [blogspot.com]
Tools, motivation (Score:4, Insightful)
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.
Paid vs Hobby (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
That depends on whether it's all fun and games. Like what you want to do is play ball, not be the groundskeeper. They can pay someone to do that. You don't want to scrub the toilet in the clubhouse. They can pay someone to do that. Same with FLOSS projects, you're there to write cool new features. Do you want to triage bugs? Write documentation? Test for regressions? Fix the build server? The fun parts will be done better, the not so fun parts is probably the other way around exactly because you're not payi
Conway's law (Score:2)
Rule #1 (Score:2)
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.
Re: (Score:1)
We make people wear a stupid viking helmet for the day when they break the build.
If it's still broken the next day, they get an Elton John T-shirt to wear.
No one's ever let it stay broken a third day.
Re: (Score:1)
Punishment cup-cakes.
If you break the build you have to bring cake ( not necessarily cupcakes) for everyone the next day - "to say sorry for negitively impacting them"
Some buy, some bake... It's now a relaxed company joke
floss is effective (Score:1)
at cleaning teeth
What makes you think FLOSS fails less? (Score:2)
Ugh (Score:2)
s/succeed/fail. Original should read:
Re: (Score:2)
I would be shocked if they could site a study that shows less than 90% fail!
Re: (Score:2)
What makes people _think_ fewer FLOSS projects fail is that people only look at the successful ones because they are the most visible. Commercial failures are very visible because of the amount of money lost, people do post mortems, studies to "make sure we don't make the same costly mistakes again". With FLOSS no one cares about the failures, they just move on to something else.
IT is not alone in this problem, take construction / civil engineering, we judge by the failures: "this bridge has cracks, there
makes me smirk (Score:1)
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.
From good FOSS projects? ... Everything. (Score:3)
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.
Sorry, typo. (Score:2)
It should say: "You shouldn't have different pipelines depending on location." ... of course. Sorry for the typo.
Representativeness heuristic (Score:1)
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 Slashd
Define "Failure" (Score:2)
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 FL
Tiny Pieces (Score:2)
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