npub1a4cfqcj5cq9qauuzz33rqq63kudnu6k7x4fe4xep93s7lu5hgk3szqt2kf (npub1a4c…t2kf) I have personally observed software development being slowed down by throwing more bodies at problem. I am admittedly only looking at the Wikipedia summary of the book (don't have the book itself on hand; I have read it though), but it states:
> Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully.
It's the diversion of senior engineers' time towards knowledge transfer to new engineers that, in my experience, can slow things down, since this (1) takes time away from contributing themselves or (2) providing direction to less experienced engineers. This cost can be reduced with good documentation and on boarding procedures in place, but sometimes a project isn't so fortunate to have this.
There is also this:
> Communication overhead increases as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.
Which I have also observed in practice. If good communication practices aren't established before new engineers are brought on, people's attention can be unnecessarily wasted with too many channels. This also hurts productivity.
I don't know if you're an outlier, but I am also not sure whether your career experience would necessarily be representative of the average/median software engineer.
Vikram Saraph /
npub1lu…ja0zr
2023-05-25 23:14:14
in reply to nevent1q…j6vn
Author Public Key
npub1luzedrhjv7er5k83wf3crewv6vmjrfxlx522003eaw9kqg8dlg8qcja0zrSeen on
wss://relay.nostr.bandPublished at
2023-05-25 23:14:14Event JSON
{
"id": "fdd7faaae326b200fe0adc1f3d42b1e079470c769589242986a4aa98f8f11fa3",
"pubkey": "ff05968ef267b23a58f1726381e5ccd33721a4df3514a7be39eb8b6020edfa0e",
"created_at": 1685056454,
"kind": 1,
"tags": [
[
"p",
"ed70906254c00a0ef3821462300351b71b3e6ade35539a9b212c61eff29745a3",
"wss://relay.mostr.pub"
],
[
"p",
"0ecb1c9b6fc91390ab51a5a39082f44c4abe0a19ad67c63b709d175ebf23e0f2",
"wss://relay.mostr.pub"
],
[
"e",
"a034a68edc557699bba90f96527234abdd7b25ab42273371d2de8234a5da45e3",
"wss://relay.mostr.pub",
"reply"
],
[
"mostr",
"https://mathstodon.xyz/users/vsaraph/statuses/110431859779550998"
]
],
"content": "nostr:npub1a4cfqcj5cq9qauuzz33rqq63kudnu6k7x4fe4xep93s7lu5hgk3szqt2kf I have personally observed software development being slowed down by throwing more bodies at problem. I am admittedly only looking at the Wikipedia summary of the book (don't have the book itself on hand; I have read it though), but it states:\n\n\u003e Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully.\n\nIt's the diversion of senior engineers' time towards knowledge transfer to new engineers that, in my experience, can slow things down, since this (1) takes time away from contributing themselves or (2) providing direction to less experienced engineers. This cost can be reduced with good documentation and on boarding procedures in place, but sometimes a project isn't so fortunate to have this.\n\nThere is also this:\n\n\u003e Communication overhead increases as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.\n\nWhich I have also observed in practice. If good communication practices aren't established before new engineers are brought on, people's attention can be unnecessarily wasted with too many channels. This also hurts productivity.\n\nI don't know if you're an outlier, but I am also not sure whether your career experience would necessarily be representative of the average/median software engineer.",
"sig": "b62a7589eeec45c56055b24c96b9c0e681e62ca175f10deab03f2d0d1d03fae02b0d659f83854faa970eb5260313a9495098123aa1391681fec5024efa4f4bf7"
}