4 ms·

> nonsense, writing a design document and a list of the possible competing implementations take time but order of magnitude less than writing and maintaining it

> nonsense, writing a design document and a list of the possible competing implementations take time but order of magnitude less than writing and maintaining it. But writing a design document may not be enough to determine if it's a good idea. Sometimes you need to try something to find out.

The_rationalist 6y ago
The observation that the design become much clearer by doing actually strengthen my argumentation.
- wtetzner 6y ago
  I think you're missing my point. If you have multiple implementations, you can be trying out implementations of different paths concurrently. If you only have one implementation, that's very hard to do. I'm not saying that's what will happen, just that the point about multiple paths works better with different teams on different code bases.
  - The_rationalist 6y ago
    . If you have multiple implementations, you can be trying out implementations of different paths concurrently. and so can you with git branches. The difference is that with multiple implementations, the team will most of the time not be aware of what is tried by the team from the other implementation (and conversely) leading to an inefficient overlap of what has been tried on the design space as I explained in another comment. If both teams worked on the same project, through the same documentation and communication channel, they would-be far more aware of what has been tried and I don't see the issue with git branches.
    - wtetzner 6y ago
      Different git branches don't allow the features to be vetted by users. At least not by many users. It's going to be much harder to get users to use different builds of Chrome than it is to have different (or even the same) people using Chrome and Firefox. Also, what management team is going to ask their developers to work on two conflicting features in parallel? It's a people matter as much as it is a technical one.

The_rationalist 6y ago

The observation that the design become much clearer by doing actually strengthen my argumentation.

wtetzner 6y ago
I think you're missing my point. If you have multiple implementations, you can be trying out implementations of different paths concurrently. If you only have one implementation, that's very hard to do. I'm not saying that's what will happen, just that the point about multiple paths works better with different teams on different code bases.
- The_rationalist 6y ago
  . If you have multiple implementations, you can be trying out implementations of different paths concurrently. and so can you with git branches. The difference is that with multiple implementations, the team will most of the time not be aware of what is tried by the team from the other implementation (and conversely) leading to an inefficient overlap of what has been tried on the design space as I explained in another comment. If both teams worked on the same project, through the same documentation and communication channel, they would-be far more aware of what has been tried and I don't see the issue with git branches.
  - wtetzner 6y ago
    Different git branches don't allow the features to be vetted by users. At least not by many users. It's going to be much harder to get users to use different builds of Chrome than it is to have different (or even the same) people using Chrome and Firefox. Also, what management team is going to ask their developers to work on two conflicting features in parallel? It's a people matter as much as it is a technical one.