4 ms·

If everyone in a corporation is unwilling to read more than a paragraph of a colleague's thoughts, it's amazing anything of any remote complexity is able to be

If everyone in a corporation is unwilling to read more than a paragraph of a colleague's thoughts, it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody.

irrational 6y ago
> it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody. Honestly, I have seen this happen so many times that I rather suspect it is fairly common.
- fxtentacle 6y ago
  Agree. It's usually one or two people building all core features and then an army of so-so skilled maintainers.
  - watwut 6y ago
    This however happen exactly when communication is bad. When two people monopolize core, won't explain what they meant by what and effectively make it impossible to split work and effectively work for others. The army of maintainers suggests that original people just move on to new functionality having others fixed their bugs. It works better when team has mechanism for knowledge sharing and core developers fix their own bugs.
    - deleted 6y ago
      [deleted]
  - user5994461 6y ago
    It's hard to have more than 2 developers working on the core of something. Development is a very non-concurrent activity. Speaking from experience, when there's multiple people trying to take over the same bit, they only create conflicting changes all over the place and deadlock the project. It's worse than if no work was not done. Now somebody needs to take the lead and remerge things manually and discard what cannot be merged. Regarding maintenance, the later army of maintainers is typically a bunch of contractors mostly sitting idle billing for time. The size of the maintenance team has little correlation to the workload.

4 ms·

If everyone in a corporation is unwilling to read more than a paragraph of a colleague's thoughts, it's amazing anything of any remote complexity is able to be

by JMTQp8lwXL 6y ago

irrational 6y ago
> it's amazing anything of any remote complexity is able to be produced by collaborative software organizations. Unless it's one guy in a corner, talking to nobody. Honestly, I have seen this happen so many times that I rather suspect it is fairly common.
- fxtentacle 6y ago
  Agree. It's usually one or two people building all core features and then an army of so-so skilled maintainers.
  - watwut 6y ago
    This however happen exactly when communication is bad. When two people monopolize core, won't explain what they meant by what and effectively make it impossible to split work and effectively work for others. The army of maintainers suggests that original people just move on to new functionality having others fixed their bugs. It works better when team has mechanism for knowledge sharing and core developers fix their own bugs.
    - deleted 6y ago
      [deleted]
  - user5994461 6y ago
    It's hard to have more than 2 developers working on the core of something. Development is a very non-concurrent activity. Speaking from experience, when there's multiple people trying to take over the same bit, they only create conflicting changes all over the place and deadlock the project. It's worse than if no work was not done. Now somebody needs to take the lead and remerge things manually and discard what cannot be merged. Regarding maintenance, the later army of maintainers is typically a bunch of contractors mostly sitting idle billing for time. The size of the maintenance team has little correlation to the workload.