3 ms·

This is known as the "mythical man month." For some reason software engineering resists more programmers equating to more productivity. I believe this is becaus

by ipnon 5y ago

This is known as the "mythical man month." For some reason software engineering resists more programmers equating to more productivity. I believe this is because of the theoretical and personal nature of programming. We are constructing in our minds ideas about how a system should exist to solve the problems at hand. By adding more programmers, we are adding more ideas, that when ineffectively communicated (certainly human nature), compound into a smorgasbord of discord and bug tickets. There is obviously some validity to your point. A 10 person startup could not run a mature company the size of Twitter. But that same 10 person startup will likely not see a double in productivity by hiring another 10 programmers. My experience has shown they will see a mysterious doubling in their miseries, and a many more "strategy meeting" to ameliorate the issues. I hope that you would agree with me that it is feasible for a skilled programmer to accomplish everything in your list in some expedient amount of time, even though it would clearly go faster if he had a buddy to work with. [0] https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month

KronisLV 5y ago
> ... But that same 10 person startup will likely not see a double in productivity by hiring another 10 programmers. ... > I hope that you would agree with me that it is feasible for a skilled programmer to accomplish everything in your list in some expedient amount of time, even though it would clearly go faster if he had a buddy to work with. Agreed. What you're describing above does sound like Brooks's law, which states that adding more manpower to a late project does make it even more late (at least as far as the mindset that you're hinting at goes): https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law Or maybe it's simply diminishing returns in your example above, which also seems valid. For the most part i've observed that in my own experience, however that's not exactly what i'm advocating for. Think more in the direction of Amdahl's law, but applied to the management of tasks within a project: https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law There will always be parts of a project which can be done in parallel and therefore should - that's not to say that it's possible to skip out on context for how they'd fit together with the greater solution, assume that all problems are interchangeable or run into any other problematic lines of thinking along the way, yet the possibilities should definitely be covered! Here's perhaps a better example from my dayjob: There are problems with the Foo view in the application, which are costing X$/month. There are also problems with the Bar reporting functionality in the application, which are costing Y$/month. Furthermore, the system needs a new Baz module developed, which is projected to bring in additional Z$/month. Also, the metrics show that historically there have been ops related issues, so introducting containers into the mix could help save W$/month, as it has already been proven in other projects. So essentially you have tasks that concern the following functionality: Foo, Bar, Baz and some DevOps stuff. So, if each task takes T amount of time, that'll be 4T in total. If you have 1 engineer they can probably develop all of that eventually, but all of the tasks will probably be addressed in whatever order they get to them, so it'll therefore also take them 4T. If you have 4 engineers AND the tasks have little overlap (this is where Amdahl's law makes a difference), they can each work on one of the tasks in parallel, so suddenly 4T becomes 1T. I think it's clear, which would lead to the highest gain, i.e. X + Y + Z + W. Of course, people always love to talk in absolutes and noone ever considers the particular circumstances of the projects. For example, in the 1M SLoC Java project that i'm currently working on, a single pizza team is pretty unlikely to step on each other's heels. Even entire features can be developed and delivered separately, without merge conflicts down the road. Whereas on another project that i'm also working on, a much smaller one, i get merge conflicts whenever i'm about to make a pull request to merge changes back into the master branch. Figuring out which project is which and what approaches and design patterns to use to minimize the pains of scaling, that's the hard part.

by ipnon 5y ago

KronisLV 5y ago

> ... But that same 10 person startup will likely not see a double in productivity by hiring another 10 programmers. ... > I hope that you would agree with me that it is feasible for a skilled programmer to accomplish everything in your list in some expedient amount of time, even though it would clearly go faster if he had a buddy to work with. Agreed. What you're describing above does sound like Brooks's law, which states that adding more manpower to a late project does make it even more late (at least as far as the mindset that you're hinting at goes): https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law Or maybe it's simply diminishing returns in your example above, which also seems valid. For the most part i've observed that in my own experience, however that's not exactly what i'm advocating for. Think more in the direction of Amdahl's law, but applied to the management of tasks within a project: https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law There will always be parts of a project which can be done in parallel and therefore should - that's not to say that it's possible to skip out on context for how they'd fit together with the greater solution, assume that all problems are interchangeable or run into any other problematic lines of thinking along the way, yet the possibilities should definitely be covered! Here's perhaps a better example from my dayjob: There are problems with the Foo view in the application, which are costing X$/month. There are also problems with the Bar reporting functionality in the application, which are costing Y$/month. Furthermore, the system needs a new Baz module developed, which is projected to bring in additional Z$/month. Also, the metrics show that historically there have been ops related issues, so introducting containers into the mix could help save W$/month, as it has already been proven in other projects. So essentially you have tasks that concern the following functionality: Foo, Bar, Baz and some DevOps stuff. So, if each task takes T amount of time, that'll be 4T in total. If you have 1 engineer they can probably develop all of that eventually, but all of the tasks will probably be addressed in whatever order they get to them, so it'll therefore also take them 4T. If you have 4 engineers AND the tasks have little overlap (this is where Amdahl's law makes a difference), they can each work on one of the tasks in parallel, so suddenly 4T becomes 1T. I think it's clear, which would lead to the highest gain, i.e. X + Y + Z + W. Of course, people always love to talk in absolutes and noone ever considers the particular circumstances of the projects. For example, in the 1M SLoC Java project that i'm currently working on, a single pizza team is pretty unlikely to step on each other's heels. Even entire features can be developed and delivered separately, without merge conflicts down the road. Whereas on another project that i'm also working on, a much smaller one, i get merge conflicts whenever i'm about to make a pull request to merge changes back into the master branch. Figuring out which project is which and what approaches and design patterns to use to minimize the pains of scaling, that's the hard part.