8 ms·

It's hard to draw a conclusion from the data unless you have a ratio. If 10x as many companies have a single founder, and 1/2 of exits are single founder exits,

by cncrnd 8y ago

It's hard to draw a conclusion from the data unless you have a ratio. If 10x as many companies have a single founder, and 1/2 of exits are single founder exits, then the lack of multiple founders could be a negative signal. That being said, I agree with the premise of the article and think that people should stop pushing collaboration so much (like open offices, pair programming). A lot of the time collaboration just makes you comfortable while adding lots of communication overhead.

graycat 8y ago
IIRC "Adding programmers to a late software project makes it later" due to the increased communications overhead. Famous remark in computing, Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, ISBN 0-201-00650-2.
- MikeTheGreat 8y ago
  That's true, but that's also talking about something else. Brooks was saying that if the project is late you can't speed it up by adding more people to it because the current team members then need to spend less time working on production and instead spend that time getting the new people up to speed. In contrast, if you're digging a ditch and that project is late then you can definitely speed it up by adding more people. They can work in parallel and the new workers already have the skills needed to contribute immediately. The GP was talking about ongoing communication overhead for people that are already on the team.
  - graycat 8y ago
    It's been a while since read the book. IIRC, you are correct. Your extra details are good, but we still can take a simpler approach: More people means more communications, of all kinds! So, the whole thing can go bureaucratic with endless lists of requirements, considerations, .... E.g., my solo, sole founder project code has 24,000 programming language statements in 100,000 lines of typing, and large organizations, even using the parallelism you mentioned, might have taken more person-hours and maybe more elapsed time to do that than I did! I had one of those situations: About a dozen of us. In the afternoon I heard the horror stories about the weeks of work they had to do to program the rule subroutines. Gads, their implementation would have made a mess out of the feature. Some of the problem was a run time routine for some RETE logic. The programmers were planning to return from all the subroutines, run the RETE code, then somehow call all the subroutines again -- at best, a disaster. By dawn I had sent e-mail with a clean solution: Carry along an entry variable pointer to the RETE routine, keep it active on the stack of dynamic descendancy, and then invoke it where as needed. I got some sleep and when I got back the production code was nearly done! How that happen? We had some bright guys, but one guy working alone overnight did better than the results of all the meetings and plannings.

by cncrnd 8y ago

graycat 8y ago

IIRC "Adding programmers to a late software project makes it later" due to the increased communications overhead. Famous remark in computing, Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, ISBN 0-201-00650-2.

MikeTheGreat 8y ago
That's true, but that's also talking about something else. Brooks was saying that if the project is late you can't speed it up by adding more people to it because the current team members then need to spend less time working on production and instead spend that time getting the new people up to speed. In contrast, if you're digging a ditch and that project is late then you can definitely speed it up by adding more people. They can work in parallel and the new workers already have the skills needed to contribute immediately. The GP was talking about ongoing communication overhead for people that are already on the team.
- graycat 8y ago
  It's been a while since read the book. IIRC, you are correct. Your extra details are good, but we still can take a simpler approach: More people means more communications, of all kinds! So, the whole thing can go bureaucratic with endless lists of requirements, considerations, .... E.g., my solo, sole founder project code has 24,000 programming language statements in 100,000 lines of typing, and large organizations, even using the parallelism you mentioned, might have taken more person-hours and maybe more elapsed time to do that than I did! I had one of those situations: About a dozen of us. In the afternoon I heard the horror stories about the weeks of work they had to do to program the rule subroutines. Gads, their implementation would have made a mess out of the feature. Some of the problem was a run time routine for some RETE logic. The programmers were planning to return from all the subroutines, run the RETE code, then somehow call all the subroutines again -- at best, a disaster. By dawn I had sent e-mail with a clean solution: Carry along an entry variable pointer to the RETE routine, keep it active on the stack of dynamic descendancy, and then invoke it where as needed. I got some sleep and when I got back the production code was nearly done! How that happen? We had some bright guys, but one guy working alone overnight did better than the results of all the meetings and plannings.