|
|
|
|
|
by pwinnski
1700 days ago
|
|
You think adding more engineers would make their software less buggy? Really? This seems contrary to literally everything I have ever read, experienced, or in any way known for my entire career, including reading books written about software engineering 30+ years ago. |
|
1. the improvements will probably come at roughly the logarithm of the number of people added at best (and, you can do worse without discipline and/or with a dysfunctional organization, possibly even negative), and
2. after their ramp-up period, like 6-9 months, during which each person might contribute a small negative load in mistakes, draining existing talent's time with questions, etc., and
3. you prioritize and value fixing bugs over adding new features, and
4. you probably want to structure those engineers in ways where they can contribute off of the critical path, like QA, dedicated to straight bug fixing, etc., and
5. You probably need an almost "microkernel" like team for very large projects--because the communication overhead grows as n^2, you need a small core, and ways to scale and build without growing the communication overhead--teams working on well defined and isolated subsystems off core, various "modules" that interface with the "microkernel core team" without imposing n^2 communication overhead between everyone working it, without breaking the product or making serious mistakes from not having n^2 connections
just thoughts, really. my intuition is: do everything right, and you can get log(added people) productivity increase time delayed (with a short term dip as those people get up to speed), up to, unfortunately, negative gain if you do much wrong