4 ms·

> we're already drones. If i wanted to be an ant, i'd join the military. Author is talking about ants as they are (which are really awesome!) rather than ants

> we're already drones. If i wanted to be an ant, i'd join the military. Author is talking about ants as they are (which are really awesome!) rather than ants as a poor metaphor for mindlessness. > lifestyle preferences of the extreme programmer As my job duties have gotten more intense and I've needed to become more productive (I say while arguing on the internet at work...) I've really come to appreciate the utility of preferences. As you need to do more, better, faster, you start figuring out the little things that maximize yourself so that you /can/. When I see SCRUM "fail" in that productivity goes down, it's not that teams produce less, it's that they fail to produce what's actually valuable. The 10x engineer doesn't write 10x the code, they write the code that's 10x the value.

trhway 11y ago
>> we're already drones. If i wanted to be an ant, i'd join the military. >Author is talking about ants as they are (which are really awesome!) rather than ants as a poor metaphor for mindlessness. it is exactly the same. Just painted with different sentiments. Self-organization by the way of deciding what to do just based on the current state of the local context is exactly the military way - you carry your order without taking in and analyzing the global context of that order. I.e. mindlessly. It is a _good_ thing there. >When I see SCRUM "fail" in that productivity goes down, it's not that teams produce less, it's that they fail to produce what's actually valuable. yes, that is one of the ways SCRUM kills productivity by design - many valuable things in software can't be (or much harder to) produced while adhering to the strict latency requirements of SCRUM and thus people/teams produce what they can instead while staying inside those latency limits. Again, it is basic system analysis - decomposing system and introducing interfaces in unnatural places just to meet the artificial requirements of the process weakens the system and leads to degradation of it. As i said - it is funny how supposedly professional system designer/developers, ie. software engineering teams and orgs, fail to see it in many cases.
- RangerScience 11y ago
  > Self-organization by the way of deciding what to do just based on the current state of the local context Isn't this only a problem because the "local context" is limited? Humans can handle really large "local contexts" (otherwise, who'd make the plan in the non-stigmertic organization?), and we can add a big set of time-dimension information to that context ("here's what we're trying to achieve and the information we have about best doing that") In the end, swarm methodologies are about empowering individual agents with intelligence and information such that they "inherently" coordinate and the result of that coordination is the desired, overall effect. "Hire good people, keep them informed, and get out of their way." But yes. The downside of things that focus on rapid iteration (which is how stigmertic stuff works) aren't good at large, single-chunk problems: if you can't iterate your way to a solution, these methods won't work for you. There are some problems and individuals that are well suited to multiple agents iterating closer to an optimal solution, and there are problems and individuals that aren't. The world has me convinced that technology development is the latter and product development is the former: it depends on how quickly I need to adapt to changes beyond my control.
  - trhway 11y ago
    > swarm methodologies are about empowering individual agents with intelligence and information man, it is gold. Sounds like a great pitch to lure into the swarm... Yet it is completely contradictory. Swarm is called swarm because it consists of insects. For swarm intelligence to work, individual intelligence must be dumpened, almost turned off, and the information dispensed to an individual must be minimal to avoid his/her swerving off its prescribed course of action that the intermediate or global plan/context may be heavily depended upon. It is like with a bricklayer or a soldier on the mission - him seeing and thus possibly trying to optimize the global plan especially by altering his mission/plan or its place/time inside the larger may affect his carrying over of the mission or the bricklaying scheme and thus endanger the bigger context. >Isn't this only a problem because the "local context" is limited? it isn't a problem. It is a feature. >Humans can handle really large "local contexts" not really. This is why we have abstraction process.
    - RangerScience 11y ago
      Oh man I experience totally the opposite. It's a trope on here, but, go to Burning Man. It's almost a definition of a human swarm, but it works specifically because everyone is empowered, informed, and relied on to resolve issues involving themselves. I also a see a parallel in how (at least one) Japanese company does their robotic assembly line: They have one or more human-operated lines, because if you don't know how to do it well, how can you teach robots how to do it well? There are lots of reasons you're wrong. One is that the situation you've described still requires someone to understand what the swarm agent needs to do - why not have that be the agent, as well? They have the most up-to-date and relevant information about their situation. Another reason you're wrong is that "swarm" doesn't consist of insects. The first software swarms were actually birds. Another reason you're wrong is that while swarms allow for success through mass action of dumb agents, the swarms actually improve as you improve the individual agents - compare the simplest ant-algorithm applied to network connectivity with one wherein the individual agents mutate and learn. Second one does a better job. ...Another reason you're wrong is that swarm agents don't have "paths" picked for them. That would (for example, in ant swarm path finding) actually prevent the swarm processing from occurring. Rather, the agents apply principles (in software, an algorithm) to the situation they're in. In other words, the global plan is in fact relying on the individuals "going off course" and trying to improve the overall situation. This all actually reminds me of both "Why I Like Java" and "Conservative vs Liberal Programming" - in that it's basically about: Do I prevent bad actors from doing harm, or do I empower good actors to make more good? If one bricklayer going off-course in detrimental way derails your plan, you don't have enough good bricklayers. Fire the bad ones and/or hire more good ones.

trhway 11y ago

>> we're already drones. If i wanted to be an ant, i'd join the military. >Author is talking about ants as they are (which are really awesome!) rather than ants as a poor metaphor for mindlessness. it is exactly the same. Just painted with different sentiments. Self-organization by the way of deciding what to do just based on the current state of the local context is exactly the military way - you carry your order without taking in and analyzing the global context of that order. I.e. mindlessly. It is a _good_ thing there. >When I see SCRUM "fail" in that productivity goes down, it's not that teams produce less, it's that they fail to produce what's actually valuable. yes, that is one of the ways SCRUM kills productivity by design - many valuable things in software can't be (or much harder to) produced while adhering to the strict latency requirements of SCRUM and thus people/teams produce what they can instead while staying inside those latency limits. Again, it is basic system analysis - decomposing system and introducing interfaces in unnatural places just to meet the artificial requirements of the process weakens the system and leads to degradation of it. As i said - it is funny how supposedly professional system designer/developers, ie. software engineering teams and orgs, fail to see it in many cases.

RangerScience 11y ago
> Self-organization by the way of deciding what to do just based on the current state of the local context Isn't this only a problem because the "local context" is limited? Humans can handle really large "local contexts" (otherwise, who'd make the plan in the non-stigmertic organization?), and we can add a big set of time-dimension information to that context ("here's what we're trying to achieve and the information we have about best doing that") In the end, swarm methodologies are about empowering individual agents with intelligence and information such that they "inherently" coordinate and the result of that coordination is the desired, overall effect. "Hire good people, keep them informed, and get out of their way." But yes. The downside of things that focus on rapid iteration (which is how stigmertic stuff works) aren't good at large, single-chunk problems: if you can't iterate your way to a solution, these methods won't work for you. There are some problems and individuals that are well suited to multiple agents iterating closer to an optimal solution, and there are problems and individuals that aren't. The world has me convinced that technology development is the latter and product development is the former: it depends on how quickly I need to adapt to changes beyond my control.
- trhway 11y ago
  > swarm methodologies are about empowering individual agents with intelligence and information man, it is gold. Sounds like a great pitch to lure into the swarm... Yet it is completely contradictory. Swarm is called swarm because it consists of insects. For swarm intelligence to work, individual intelligence must be dumpened, almost turned off, and the information dispensed to an individual must be minimal to avoid his/her swerving off its prescribed course of action that the intermediate or global plan/context may be heavily depended upon. It is like with a bricklayer or a soldier on the mission - him seeing and thus possibly trying to optimize the global plan especially by altering his mission/plan or its place/time inside the larger may affect his carrying over of the mission or the bricklaying scheme and thus endanger the bigger context. >Isn't this only a problem because the "local context" is limited? it isn't a problem. It is a feature. >Humans can handle really large "local contexts" not really. This is why we have abstraction process.
  - RangerScience 11y ago
    Oh man I experience totally the opposite. It's a trope on here, but, go to Burning Man. It's almost a definition of a human swarm, but it works specifically because everyone is empowered, informed, and relied on to resolve issues involving themselves. I also a see a parallel in how (at least one) Japanese company does their robotic assembly line: They have one or more human-operated lines, because if you don't know how to do it well, how can you teach robots how to do it well? There are lots of reasons you're wrong. One is that the situation you've described still requires someone to understand what the swarm agent needs to do - why not have that be the agent, as well? They have the most up-to-date and relevant information about their situation. Another reason you're wrong is that "swarm" doesn't consist of insects. The first software swarms were actually birds. Another reason you're wrong is that while swarms allow for success through mass action of dumb agents, the swarms actually improve as you improve the individual agents - compare the simplest ant-algorithm applied to network connectivity with one wherein the individual agents mutate and learn. Second one does a better job. ...Another reason you're wrong is that swarm agents don't have "paths" picked for them. That would (for example, in ant swarm path finding) actually prevent the swarm processing from occurring. Rather, the agents apply principles (in software, an algorithm) to the situation they're in. In other words, the global plan is in fact relying on the individuals "going off course" and trying to improve the overall situation. This all actually reminds me of both "Why I Like Java" and "Conservative vs Liberal Programming" - in that it's basically about: Do I prevent bad actors from doing harm, or do I empower good actors to make more good? If one bricklayer going off-course in detrimental way derails your plan, you don't have enough good bricklayers. Fire the bad ones and/or hire more good ones.