(no subject)
Never thought I'd see the day when suits talk amongst themselves about some stuff I made:
Property Portal Watch on Transit Maps - A website all about real estate websites.
AIM Group on Transit Maps - Site is bar-graph themed, includes tabs for "Real Estate" and "Automotive".
--==--
Aimee and I just returned from a weekend trip to Oregon, WHEREIN we had breakfast with Ellen Range in Eugene, and danced to the world's largest contra band in Portland. Now for some Q&A:
Q: When will The Singularity occur?
A: Ray Kurzweil, in his 2006 book "The Singularity Is Near", based on order-of-magnitude estimates of the capacity of the human brain (~10^15 instructions/second) and the steady exponential increase in non-biological computing power (doubles about once every two years), estimates The Singularity should occur some time around 2025.
Q: Bacon Maple Bar?
A: Yes.
--==--
I've reimplemented Workstack. It's here:
http://workstack.appspot.com/task/b445c84c0f3411deb48b090a5f4ffd46
Notice my use of the super-trendy and theoretically dubious randomly generated UUID as item ID. ANYWAY:
We have all sorts of problems: AIDS isn't cured yet. Our manufacturing practices doom our grandchildren to a life elbow-deep in toxic shit. Sometimes we build cities that aren't any fun to live in. Some embarrassing portion of American adults are obese. PROBLEMS. Meanwhile, lots of people are unemployed - they claim that they have nothing to do. The management system we're using to allocate resources to problems appears to be functioning fairly inefficiently. WHAT THE HELL, CAPITALISM.
So allow me to recommend a minor retrofitting to the bare capitalist system: when you've got a problem what needs working on, you go to the town square and set up a sign that clearly announced the problem you would like to work on: "Donuts not yet free" or whatever. If you've got a bit of spare time on your hands and you'd like to work on something of consequence, you go to the town square, take a look around, and pick the project that fits your abilities and interests. It's good for society, but it's also good for the individual: top contributors become known for their prowess, and may, among other benefits, be invited to tasty home-cooked meals by attractive people.
This seems like a good, solid, utopian idea. I'm not the first person to think of it. There's actually a chapter in A Pattern Language describing it. It doesn't actually happen though, and I believe the reason is widespread inability to internally manage such projects. Specifically, current project management systems are not designed to harness piecemeal and unreliable workers, and they are not built to tackle problems to which the solutions are not yet known.
As far as I can tell, this is how project management currently works: you enumerate all tasks that belong to the project. You figure out what each task depends on - the graph of what tasks will precede and succeed each task. Together with estimates of how long each task will take you can determine the "critical path" of a project - the longest chain of dependencies - which will tell you how long the project will take. You can then start telling your workers when and where they will be needed, and whether any delay in their task will result in a delay of the whole project, or whether their task has some "float" - its delay will not delay the whole project.
This method depends on three things (from the wikipedia article "Critical Path"):
1. A list of all activities required to complete the project.
2. The time (duration) that each activity will take to completion.
3. The dependencies between the activities.
This is all well and good if you're building an office building or prosecuting a legal case - if you're doing things that you already know how to do. But if you're attempting to solve a problem that has never been solved before, you don't have any of these pieces of information. You don't know what activities will be involved in the solution. You don't know how long they will take. You don't know what they depend on. Even worse, you can't assign someone to a task or in any way hold anyone responsible to the completion of a task, because all labor is completely volunteer.
So how shall we manage the labor of a cloud of volunteers to a task with no known solution?
There is one class of problems where the solution is never known beforehand - how to write software to automate a previously unautomated task. Good software engineers are always working at the very limits of their knowledge, because if they weren't working at the limits of their knowledge they're working on something that has been done several times, and anything that can reliably done repeatedly then it can be automated using software. Hackers are therefore doomed to constantly beat an ignorant, wandering path through the wilderness of unsolved problems, leaving behind a paved trail of automated tasks.
And there is a class of software projects where the workers are unreliable volunteers - open-source software projects.
I've been working on a system which intends to tackle this problem, partially by incorporating some of the conventions I've seen used in the production of open source software. I don't really have it figured out, though - my process is sort of a half-baked extension of the workstack app I built to keep myself on task.
The basic idea is this: the software should allow people to use their spare labor the greatest effect by matching them to the highest priority task that matches their interests and abilities. The simplest implementation would be a large and unstructured collection of task records explaining what the task is all about and what skills it would require to complete. People can rate the importance of tasks, which would serve to prioritize them.
Property Portal Watch on Transit Maps - A website all about real estate websites.
AIM Group on Transit Maps - Site is bar-graph themed, includes tabs for "Real Estate" and "Automotive".
--==--
Aimee and I just returned from a weekend trip to Oregon, WHEREIN we had breakfast with Ellen Range in Eugene, and danced to the world's largest contra band in Portland. Now for some Q&A:
Q: When will The Singularity occur?
A: Ray Kurzweil, in his 2006 book "The Singularity Is Near", based on order-of-magnitude estimates of the capacity of the human brain (~10^15 instructions/second) and the steady exponential increase in non-biological computing power (doubles about once every two years), estimates The Singularity should occur some time around 2025.
Q: Bacon Maple Bar?
A: Yes.
--==--
I've reimplemented Workstack. It's here:
http://workstack.appspot.com/task/b445c84c0f3411deb48b090a5f4ffd46
Notice my use of the super-trendy and theoretically dubious randomly generated UUID as item ID. ANYWAY:
We have all sorts of problems: AIDS isn't cured yet. Our manufacturing practices doom our grandchildren to a life elbow-deep in toxic shit. Sometimes we build cities that aren't any fun to live in. Some embarrassing portion of American adults are obese. PROBLEMS. Meanwhile, lots of people are unemployed - they claim that they have nothing to do. The management system we're using to allocate resources to problems appears to be functioning fairly inefficiently. WHAT THE HELL, CAPITALISM.
So allow me to recommend a minor retrofitting to the bare capitalist system: when you've got a problem what needs working on, you go to the town square and set up a sign that clearly announced the problem you would like to work on: "Donuts not yet free" or whatever. If you've got a bit of spare time on your hands and you'd like to work on something of consequence, you go to the town square, take a look around, and pick the project that fits your abilities and interests. It's good for society, but it's also good for the individual: top contributors become known for their prowess, and may, among other benefits, be invited to tasty home-cooked meals by attractive people.
This seems like a good, solid, utopian idea. I'm not the first person to think of it. There's actually a chapter in A Pattern Language describing it. It doesn't actually happen though, and I believe the reason is widespread inability to internally manage such projects. Specifically, current project management systems are not designed to harness piecemeal and unreliable workers, and they are not built to tackle problems to which the solutions are not yet known.
As far as I can tell, this is how project management currently works: you enumerate all tasks that belong to the project. You figure out what each task depends on - the graph of what tasks will precede and succeed each task. Together with estimates of how long each task will take you can determine the "critical path" of a project - the longest chain of dependencies - which will tell you how long the project will take. You can then start telling your workers when and where they will be needed, and whether any delay in their task will result in a delay of the whole project, or whether their task has some "float" - its delay will not delay the whole project.
This method depends on three things (from the wikipedia article "Critical Path"):
1. A list of all activities required to complete the project.
2. The time (duration) that each activity will take to completion.
3. The dependencies between the activities.
This is all well and good if you're building an office building or prosecuting a legal case - if you're doing things that you already know how to do. But if you're attempting to solve a problem that has never been solved before, you don't have any of these pieces of information. You don't know what activities will be involved in the solution. You don't know how long they will take. You don't know what they depend on. Even worse, you can't assign someone to a task or in any way hold anyone responsible to the completion of a task, because all labor is completely volunteer.
So how shall we manage the labor of a cloud of volunteers to a task with no known solution?
There is one class of problems where the solution is never known beforehand - how to write software to automate a previously unautomated task. Good software engineers are always working at the very limits of their knowledge, because if they weren't working at the limits of their knowledge they're working on something that has been done several times, and anything that can reliably done repeatedly then it can be automated using software. Hackers are therefore doomed to constantly beat an ignorant, wandering path through the wilderness of unsolved problems, leaving behind a paved trail of automated tasks.
And there is a class of software projects where the workers are unreliable volunteers - open-source software projects.
I've been working on a system which intends to tackle this problem, partially by incorporating some of the conventions I've seen used in the production of open source software. I don't really have it figured out, though - my process is sort of a half-baked extension of the workstack app I built to keep myself on task.
The basic idea is this: the software should allow people to use their spare labor the greatest effect by matching them to the highest priority task that matches their interests and abilities. The simplest implementation would be a large and unstructured collection of task records explaining what the task is all about and what skills it would require to complete. People can rate the importance of tasks, which would serve to prioritize them.