4 ms·

Mythical Man Month applies to new product development, when you have a product you're trying to rush out the door that doesn't exist yet. Once the project alre

Mythical Man Month applies to new product development, when you have a product you're trying to rush out the door that doesn't exist yet. Once the project already exists, is largely feature-complete, and is mostly in the "fixing bugs and small annoyances" phase, then Linus's Law [1] takes over. Debugging is very much parallelizable, because you can generally fix the bug without generating major impact elsewhere in the codebase, and if you have a good test suite you'll know if your fix has broken other invariants elsewhere. [1] https://en.wikipedia.org/wiki/Linus%27s_law https://en.wikipedia.org/wiki/Linus%27s_law

munificent 2y ago
> Once the project already exists, is largely feature-complete That may be a reachable state for a command-line oriented operating system itself a clone of an older operating system, but is likely unrealizable in any sort of system that is trying to be actively more innovative. > mostly in the "fixing bugs and small annoyances" phase I don't know of any UI framework that has had the luxury of ever reaching that phase. > then Linus's Law [1] takes over. If you maintain a widely used framework, I think the more meaningful eponymous law is Hyrum's: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ This is probably the #1 source of friction for contributing to Flutter. It's not that the Flutter developers are overworked killjoys who don't value external contributors. It's that when, as the author of the blog post says, your codebase has a million users, it's really hard for a contribution to not end up breaking someone. > if you have a good test suite you'll know if your fix has broken other invariants elsewhere. Sure, but the fix itself will still need tests. So now you've got to walk the contributor through the process of writing tests which is definitely not a skill that most software engineers have and is not particularly rewarding for an external contributor who already has a working fix and just wants their patch to be "done". Fundamentally, coordinating thousands of people to make a single codebase used by millions of people is hard. There is no silver bullet. It's a miracle it works at all.
maxrmk 2y ago
I thought linus had lost it for a second there, until I saw it's just named after him and not something he created. I generally disagree - I think that having many developers with a shallow understanding of the whole codebase scales less-than-linearly with the number of devs. It's probably less actively harmful than new product development, but I'd still say a team of 50 is probably larger than is necessary for the amount of usage flutter gets.
p1necone 2y ago
Having a large number of devs spot fixing issues as they come up without a deep understanding of the codebase is how you turn a maintainable project into a mess.

munificent 2y ago

> Once the project already exists, is largely feature-complete That may be a reachable state for a command-line oriented operating system itself a clone of an older operating system, but is likely unrealizable in any sort of system that is trying to be actively more innovative. > mostly in the "fixing bugs and small annoyances" phase I don't know of any UI framework that has had the luxury of ever reaching that phase. > then Linus's Law [1] takes over. If you maintain a widely used framework, I think the more meaningful eponymous law is Hyrum's: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ This is probably the #1 source of friction for contributing to Flutter. It's not that the Flutter developers are overworked killjoys who don't value external contributors. It's that when, as the author of the blog post says, your codebase has a million users, it's really hard for a contribution to not end up breaking someone. > if you have a good test suite you'll know if your fix has broken other invariants elsewhere. Sure, but the fix itself will still need tests. So now you've got to walk the contributor through the process of writing tests which is definitely not a skill that most software engineers have and is not particularly rewarding for an external contributor who already has a working fix and just wants their patch to be "done". Fundamentally, coordinating thousands of people to make a single codebase used by millions of people is hard. There is no silver bullet. It's a miracle it works at all.

maxrmk 2y ago

I thought linus had lost it for a second there, until I saw it's just named after him and not something he created. I generally disagree - I think that having many developers with a shallow understanding of the whole codebase scales less-than-linearly with the number of devs. It's probably less actively harmful than new product development, but I'd still say a team of 50 is probably larger than is necessary for the amount of usage flutter gets.

p1necone 2y ago

Having a large number of devs spot fixing issues as they come up without a deep understanding of the codebase is how you turn a maintainable project into a mess.