Sep 28 2012: Yeah, actually that would be ideal - show that a problem has multiple solutions, and then let the voters just pick the one they like best (or hate the least).
Sep 27 2012: Try github - it really take a lot of the mystery out of it. They have really simplified the concept of pushing and pulling with the idea of pull requests and the github downloadable app. They have a lot of great tutorials on their site as well.
Using git as an example, when there is a conflict, the two programmers can do one of two things:
a: Discuss the conflict and come to a resolution together and adopt a single common project.
b: Agree to disagree and decide to branch off from each other with their separate solutions.
At first glance, solution b seems problematic, why can't they just agree on a solution? Well, there are often scenarios when you want the program to branch off into two different solutions - maybe both programmers have a vision for where the project should go, and they are both valid visions that are just inherently different programs. One wants to make the solution web-based, the other wants to make the solution into a mobile app. Any programmer can decide to take any other programmer's work as their starting point, or to take any other programmer's changes as 'canonical' for their own purposes. People gravitate towards the developers with the most respect in the community (just like all other social arenas) and if you are going to disagree with Linus Torvalds, you better have a damn good reason.
In effect, this means that yes, sometimes projects fork off from each other, but this is a natural part of the development process, and is not something to be discouraged. In practice, it means more choices for the users of the software.
TEDCred score: +0.50 TEDCred reflects your contribution to the TED community.
A reply on Conversation: At about 10:42 Clay talks about "cooperation w/o coordination". My question is: What if those two programmers made contradictory changes?
A reply on Conversation: At about 10:42 Clay talks about "cooperation w/o coordination". My question is: What if those two programmers made contradictory changes?
A comment on Conversation: At about 10:42 Clay talks about "cooperation w/o coordination". My question is: What if those two programmers made contradictory changes?
Using git as an example, when there is a conflict, the two programmers can do one of two things:
a: Discuss the conflict and come to a resolution together and adopt a single common project.
b: Agree to disagree and decide to branch off from each other with their separate solutions.
At first glance, solution b seems problematic, why can't they just agree on a solution? Well, there are often scenarios when you want the program to branch off into two different solutions - maybe both programmers have a vision for where the project should go, and they are both valid visions that are just inherently different programs. One wants to make the solution web-based, the other wants to make the solution into a mobile app. Any programmer can decide to take any other programmer's work as their starting point, or to take any other programmer's changes as 'canonical' for their own purposes. People gravitate towards the developers with the most respect in the community (just like all other social arenas) and if you are going to disagree with Linus Torvalds, you better have a damn good reason.
In effect, this means that yes, sometimes projects fork off from each other, but this is a natural part of the development process, and is not something to be discouraged. In practice, it means more choices for the users of the software.